Re: settle.network

Hi Stan,

Welcome to the Interledger CG!

I think Settle is very interesting and quite similar to what we're setting
up with ilp-kit <https://github.com/interledgerjs/ilp-kit>, as Adrian
mentioned.

A clarification about the whitepaper: even though it describes two modes,
shortly after writing the paper we decided that the "Interledger Protocol"
as such would only be Universal mode. So ILP uses the same 2-phase commit
flow as Lightning and Settle. Atomic mode may be used within predetermined
groups of participants but it's not, well, universal.

Regarding how multi-hop payments are set up, the four key parts are:

   - Interledger addresses are used to identify ledgers and accounts. The
   address format is documented here
   <https://github.com/interledger/rfcs/pull/154>
   - Interledger Quoting Protocol (ILQP) is used by senders to request a
   quote from a connector. The documentation for this is in the works but you
   can get an idea of what this looks like here
   <https://gist.github.com/justmoon/a59fd43958ce421c8b4a88d5143c718b#quoting-request-example>
   - The Interledger Packet is attached to each local transfer to tell the
   next connector where to forward or deliver the funds. It includes the
   destination amount, the destination address, and extra data.
   - The routing protocol, or Connector-to-Connector Protocol (CCP),
   entails connectors broadcasting rate curves to one another for each path
   they know. Connectors store routes in local routing tables to handle quote
   requests and incoming payments. This is implemented in ilp-routing
   <https://github.com/interledgerjs/ilp-routing>

We took inspiration from the Internet in separating routing from the other
3 components, because routing protocols always need to be updated. That
design has allowed the Internet's routing protocol to be updated a half a
dozen times without most users being any the wiser because the address and
packet did not change.

As you pointed out, another key part of Interledger is the ledger layer
abstraction. This is roughly summed up by the Javascript Ledger Plugin
Interface
<https://github.com/interledger/rfcs/blob/master/0004-ledger-plugin-interface/0004-ledger-plugin-interface.md>.
This can be used for centralized, decentralized, and even "virtual" ledgers.

The plugin that might interest you the most is ilp-plugin-virtual
<https://github.com/interledgerjs/ilp-plugin-virtual>, which implements
bilateral trust/credit lines. This is what's being used for ilp-kit
"peering". One of the cool parts about having this implemented as just
another plugin is that these credit relationships can be used
interchangeably alongside prefunded payment channels like Lightning or
conditional payments on ledgers.

Best,
Evan

On Tue, Feb 28, 2017 at 2:13 AM Stanislas Polu <polu.stanislas@gmail.com>
wrote:

(Jumping on on this thread)

Hi! I'm the author of Settle[0]. Happy to answer any question and hear
feedback about the project obviously!

Additionally, wanted to thank you for posting this here sine it gave
me a chance to learn more about interledger!

I had a few questions myself on the project. After reading the
whitepaper[1] as  well as the ilp-kit wiki[2] (as pointed by Ryan
Fugger), I was wondering how the interledger allows multi-hop
transactions through "untrusted" parties (at least untrusted by the
recipient or the sender) without any notion of trust baked in the
protocol?

On this, the paper states:

> In the following, we assume that a path has already been
> chosen and the exchange rates and any fees quoted by
> the connectors in C are known.

Which seems to be like a crucial phase of any multi-hop payments?

Additionally, what I intended to demonstrate with Settle is that if
trust is expressed in the network, you can provide atomic safe
multi-hop transactions without the need for a consensus algorithm if
you accept that any actor can loose up to the amount of trust he has
in a faulting actor (which feels, at least personally, an extremely
reasonable constraint). That protocol also relies on an hash lock
escrow / 2 phase commit mechanism, but does not require notaries which
I think is pretty nice.

I'd love to hear more about the interledger approach on this.

More generally, I find the interledger approach --providing a standard
API for ledgers to participate in a global payment network instead of
mandating a "ledger format"-- extremely interesting (In settle one
could syncrhonize the state of a mint with the state of a local ledger
to achieve this, but that's somewhat clumsier). Would love to explore
how concepts of Settle could help here and happy to get involved as
needed if that makes any sense.

-stan

[0] https://settle.network
[1] https://interledger.org/interledger.pdf
[2] https://github.com/interledgerjs/ilp-kit/wiki


-- 

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>