From @adrianhopebailie on Fri Nov 16 2018 13:16:27 GMT+0000 (UTC)
We have started to use
peer. addresses for various peer protocols.
Let’s use this thread to capture some ideas on formalizing this and then we can update the address spec if necessary. IL-RFC 15 currently defines this address space as:
“Addresses for exchange of packets only with a direct peer. Connectors MUST NOT forward packets with peer. addresses. Packets exchanged between peers to pass routing and config information will use peer. addresses.”
One of the great features of the ILP address space is the extensible nature and (almost) infinite sub-addressing that is possible. This means we can do convenient things like add a sub-address space per application or protocol and then still further divide the space up for per session or per transaction addresses.
So, one could take the
peer.config address space and say that packets addressed to that address are directed at the ‘config’ module/application on the peer.
We could (should?) go further and be more specific. E.g. to describe the logical service that a message is addressed to, like:
Or describe the sub-protocol being exchanged via ILP:
We could also add some specific suffixes to allow more efficient filtering, like:
Another thought is to define a standard for using the condition and fulfill fields to provide some message validation between peers rather than simply using hard-coded values. Given that
peer. packets never traverse the network this should have no impact.
As @sappenin has pointed out in the past, it’s not clear why we do some direct peer messaging at the “ledger” layer (i.e. via BTP) and some at the ILP layer (i.e. using
peer. addressed ILP packets.
Should we encourage both? Are the use cases different enough?
One advantage to doing everything in ILP packets is that we dramatically simplify the bi-lateral transport layer requirements.
We still have a single reference connector implementation (that is used widely) so changes are possible now without much ecosystem impact but that window will soon pass. I feel like we’ve done enough experimenting to look at the various use cases and start extracting abstractions that can be re-used (enforced) going forward.
Please provide your thoughts here!
Copied from original issue: https://github.com/interledger/rfcs/issues/496