ILSP addresses

[michielbdejong]

Rethinking a conversation with @sappenin yesterday, now that Interledger payments no longer touch the underlying ledgers directly, Alice is no longer sending money "to Bob@Ledger", she is sending it "to Bob@Connector" (and then Bob has a custom settlement/clearing agreement with Connector where "the Ledger" gets involved, but that part is now irrelevant to Alice). So maybe it makes more sense to replace the "ledger prefixes" in ILP addresses with "connector prefixes", and consider ILP addresses more as ILSP addresses?

[michielbdejong]

I actually already did this without thinking much about it, on the testnet. In 17Q4, there was a ledger prefix test.crypto.xrp.<address>. In 18Q1, there is an account prefix test.amundsen.bmp.btp18q1xrp.<paychanId>! :)

[sharafian]

:+1: The connector also takes an ILP address in its configuration now rather than having an ILP address for every ledger that it's on. I don't think we should change ILP address to ILSP address, though; the name just means they're the addresses used in ILP, not that they denote a ledger.

[emschwartz]

There are a couple reasons I don't find it all that surprising that ILP addresses are primarily for connectors rather than ledgers:

1. Connectors are the party that actually speak ILP, so it makes sense that they are the main actors in the Interledger system
2. A confusing part about ILP addresses previously was how to deal with connectors that have accounts on multiple currencies: would they have multiple ILP addresses that would each correspond to one currency? If a user has an account with a connector denominated in a small or obscure currency, but that connector is more easily reached through two different larger currencies, what would the user's address look like, or would they need multiple addresses?
3. We always assumed that connectors that use the same currency would be able to forward packets to one another, but that's a highly questionable assumption. Just because two connectors use a major currency like USD doesn't mean they have a direct connection to one another or even know a route between one another

[justmoon]

The old view also created somewhat of a routing issue. If I'm using the address test.crypto.xrp, I've told you I want to go to XRP, but there may be different competing XRP integrations (using different plugins), so who actually "owns" test.crypto.xrp? You'd have to have a standards effort that defines exactly what a test.crypto.xrp integration must look like to be "compliant". And then you need to registry that assigns test.crypto.xrp to that standards effort.

Note that the view where every address just refers to a connector is a lot less political - connectors simply decide bilaterally how they want to do things vs there is a global standard how all connectors have to integrate with this ledger which inevitably creates political debate because some ways to integrate will be better for some people's interests.

When every address refers to a connector it also allows things like authenticated routing. (The current routing protocol doesn't contain a PKI yet, but it contains enough functionality for us to add a basic form of authenticated routing in the future.) There needs to be a connector that is originating each route for that route to have any kind of key associated with it. Otherwise, you'd once again need some kind of "community cryptographic key" that represents test.crypto.xrp.

In the end, I find that a hundred different avenues all lead to the same conclusion: If you create a new protocol, it makes a lot of sense for that protocol to be used between participants that are explicitly aware of it. One of the earliest points we made in Five Bells (pre-Interledger) history was that ledgers are conservative and slow to adopt technology. To illustrate, I used this picture of a bank in a presentation we gave in February 2015. Note how the building barely changed even as the city of San Francisco was built around it.

The point was ledger interfaces would evolve slowly and we wanted to require the absolute minimum possible change to ledger interfaces. That's what lead to the escrow concept and ledger plugin API.

Fast forward a couple of years and with ILPv4 we finally have a version that requires zero changes to ledgers. That is the logical conclusion of this work. It just wasn't something we knew how to do back in 2014 when we started. (Though it seems obvious in retrospect since everyone else from VISA to PayPal to Transferwise etc. already basically does this for much the same reason - the underlying ledgers are too slow and expensive to wait for them, so you settle net and you settle later.)

[justmoon]

Should add that I totally get where you're coming from. If the first thing we told you about ILP is that it's about connecting ledgers, that's still true but probably not how I would explain it today. But I also think that it's healthy to be able to question your assumptions if you have a good reason and I think we have good reasons for these transitions (some of which @emschwartz outlined and I tried to add to above.)

More on topic: Agree with @sharafian. Changing it to "ILSP address" only makes sense for the people that were part of the community prior to this shift. For everyone new to ILP, it'd be confusing why ILP addresses aren't just called ILP addresses.

Still, good point pointing out this shift. It's easy to gloss over major transitions like this, so I appreciate you stopping to point out there was a big change here.

[emschwartz]

Can this be closed now?

[michielbdejong]

Yes! I have some thoughts about how we can explain ILP addresses in the new version of the whitepaper, we can work on that next week! :)