Closed michielbdejong closed 7 years ago
That means that for instance paychan settlement claims are more low-level than the sha256 hashlocks used by ILP, even if manual out-of-band settlements are not.
I don't follow this point. Settlement claims and manual settlement are both part of the ledger layer I would say. The definition is that the ledger layer contains everything you need to transact with people on the same "ledger" as you. (The "ledger" could be a trustline.) Meanwhile, the Interledger layer contains protocols that allow you to transact with someone who isn't on your ledger. Of course, it's fine to use Interledger even for local transactions if doing so is convenient, but that doesn't change the fact that you could just use the ledger layer.
So as far as settlement goes - that is only between you and your peer, so clearly it's on the ledger layer.
BTP sort of took this approach of grouping quotes and payments into one "layer", and I briefly experimented with a BTP-centric software architecture, but since then we decided to stick to ledger-centric view, where sending a message to a connector is something very different than sending a message to a ledger.
We think of Interledger as an ILP layer on top of a ledger layer. That means that for instance paychan settlement claims are more low-level than the sha256 hashlocks used by ILP, even if manual out-of-band settlements are not. It also means that
sendTransfer
is a first-class citizen of the RPC API, butquote_by_source/dest/curve
andbroadcast_routes
are requests that get packaged inside other request.But you could also think of ILP as a chain of transfers from one party to another, without defining if the next party in the chain is a ledger, an end user, or a connector.
From that perspective, I would say the comms layer is the lowest layer between two connectors, and is one of:
Then there's the message layer, that contains lots of different messages, for:
And then on top of the ILP-chaining layer, the address layer is the single agreed ILP address space, i.e. the exact destination address string is also forwarded along the chain. But an implementation of the ILP chaining layer could support both our current address format and other ways of indicating a payment's destination.
And on top of that address layer is the end-to-end ILP packet forwarding layer, where not only the payment and the ILP address arrive at the destination during the prepare phase, but also the exact rest of the ILP packet that was included in the first transfer.
Not sure if we would want to do something with this, but I thought I would just write up my thoughts about it. :)