Defining the ecosystem: ILSPs and Wallets

[adrianhopebailie]

I think it would be useful for us to document the roles that we see in the ecosystem so that we can better plan the interfaces and software required. I have started by putting the following diagram together to indicate the different scenarios I imagine for a user wallet.

The purpose of this issue is to create a thread for discussion, following which I'll document this more formally somewhere.

Scenario A

In the diagram, User A has a wallet where the source of funds are controlled by the user (likely they are a crypto-currency like BTC, ETH or XRP). This could be the case for many existing wallets today where the wallet is just software that assists the user in submitting signed transactions to the distributed ledger.

The wallet will also have an interface to an Interledger Service Provider that provides the gateway into the Interledger. The ILSP will be responsible for providing quotes to the user and also routing payments. I'd imagine the flow being:

1. Wallet A gets an IPR or uses SPSP to establish the address, condition, expiry and possibly amount to send.
2. If necessary the wallet gets a quote from the ILSP.
3. The wallet submits a conditional transfer to the ledger in favour of the ILSP and sends the ILP payment packet to the ILSP.
4. The ILSP routes the payment onto the Interledger and ultimately returns a response (fulfillment or error) to the wallet. If the response is a fulfillment then the ILSP gets paid on the ledger.

The advantage of this arrangement is that the user can have a single source of funds but potentially many ILSPs, but most importantly the user places no trust in the ILSP with regard to their money. The user only has to trust the ledger/network on which they perform the transfers to the ILSP.

A disadvantage is that the wallet must be sophisticated enough to perform the conditional transfer directly on the ledger.

It's likely that the interface between the wallet and ILSP would become standardized (using something like the Common ledger Protocol). Authentication of this interface is less onerous as there are no funds at risk if the user's access to the interface is compromised.

Scenario B

In the diagram, User B has a wallet where the source of funds are controlled by the ILSP. This is the case with exchanges and banks today so really this scenario is where an existing service provider that holds funds for customers offers them the ability to use those funds to make ILP payments.

In this case the interface between the wallet and the ILSP could be entirely proprietary but would likely offer some basic functions like: "Get a quote", "Make a payment", "Check my balance" etc.

Since the execution of any pre-payment setup (SPSP or getting an IPR) would likely happen at the wallet, the interface to the ILSP would need to facilitate some exchange of ILP-specific (as opposed to just generic payments) data like ILP-addresses, conditions etc.

I'd expect the flow to be something like:

1. Wallet B gets an IPR or uses SPSP to establish the address, condition, expiry and possibly amount to send.
2. If necessary the wallet gets a quote from the ILSP.
3. The wallet submits a payment instruction to the ILSP.
4. The ILSP makes the payment on the Interledger and ultimately gets a response (fulfillment or error).
5. The ILSP responds to the wallets payment instruction.

The advantage of this arrangement is that the wallet is pretty simple. It doesn't need to have any ILP-specific functions as it can simply pass data to the ILSP to interpret.

An obvious disadvantage is that the user's funds are held by the ILSP so clearly they can only use that ILSP with those funds.

Scenario B (extended)

It is possible though that a wallet could be developed that aggregates the interfaces to multiple funds-holding ILSPs. This could then get quotes from all of them and allow the user to select how they wish to complete a payment.

[emschwartz]

If I'm understanding it properly, I don't think Scenario B is something we want to encourage. It's much more powerful if ILSPs expose standard protocols rather than implementing custom interfaces. Wallets should be built to understand ILP.

@justmoon made the point elegantly when he said something like "the Internet would have been a lot worse if your ISP sent you faxes or printouts of websites you wanted to see instead of providing you with standard IP access"

I think the interface to an ILSP should be:

• A ledger (plugin) protocol - There can be many variants but we should try to get the Common Ledger Protocol to the point where you want to use it (or maybe it plus some extensions) for most ledger protocols.
• Standard ILP
• Standard ILQP

It would be nice (though not strictly necessary) for all of those to use a consistent encoding, which was one of the motivations for switching CLP to OER.

Overall, I don't think I'm understanding why this way of framing the diagrams would be more helpful than the current model of "There are ledgers and connectors. Sometimes the ledger and connector is the same party. You talk to the ledger using a ledger protocol and you talk to the connector using ILP and ILQP".

[adrianhopebailie]

Overall, I don't think I'm understanding why this way of framing the diagrams would be more helpful than the current model of "There are ledgers and connectors. Sometimes the ledger and connector is the same party. You talk to the ledger using a ledger protocol and you talk to the connector using ILP and ILQP".

Because they have vastly different implications. You have said we should not encourage Scenario B but that is just "the ledger and connector is the same party".

If you are suggesting wallets should only support scenario A then you are also saying ILP-enabled wallets should only use public-ledgers that support conditional payments. That's likely less than 1% of payments today.

When you talk about using a standard ledger protocol like CLP I'm not sure I understand who hosts the CLP interface and speaks the native ledger protocol of the ledger?

[emschwartz]

Ok, sure. I don't mean this in a rude way, but so what? I'm still not sure what the implication of looking at it this way is.

[adrianhopebailie]

"Hi, I am a wallet publisher. ILP looks like something I want to support in my product. What do I need to do?"

[emschwartz]

Sure, sounds like a useful doc.

As far as I can tell, the main point of this initial writeup is to say:

• Users use some client software or API to send payments through their Interledger Service Provider
• An ILSP can play either the role of an Interledger connector or a connector and a ledger
• ILSPs must ILP, ILQP, and a ledger protocol of their choice (though a variant of CLP may be recommended and one that implements HTLCs + authenticated messaging is strongly recommended)
• ILSPs connect to other ILSPs and that makes up the Interledger

(This is not a bad thing but it doesn't seem like this is a radically new way to define the ecosystem. I'd be slightly worried that introducing new terminology for the same or similar roles to what we've talked about before and in other docs will be more confusing than helpful. Sometimes it's better to stick with existing terms rather than adding more to the list of things you need to understand)

[adrianhopebailie]

This is not a bad thing but it doesn't seem like this is a radically new way to define the ecosystem. I'd be slightly worried that introducing new terminology for the same or similar roles to what we've talked about before and in other docs will be more confusing than helpful. Sometimes it's better to stick with existing terms rather than adding more to the list of things you need to understand

We need to be cognizant of the different stakeholders here. We are at a stage where we want to start appealing to "users" of the network not just participants.

So while the existing terminology is fine for someone operating a node I think the ILSP term is useful and we need to define it properly.

ILSPs will be the gateways to the Interledger for the majority of people. They'll expect to pick up some software that says it can do payments via ILP and following some basic config be using that software and making payments. Or they'll expect to log into their ILSP and get some info like their ILP-address or SPSP endpoint address or user@host identifier and then be able to give that to services or people that want to send them ILP payments.

There is an opportunity for us to define what that interface should look like in a way that makes sense for ILP (not just a generic payments API). We have talked about the asymmetric trustlines API in this vein before but never formally documented this.

If we do so then we provide a resource for:

1. ILSPs who can host the interface we define for their users
2. Software developers who will consume the API of an ILSP on behalf of their users.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. \n\n If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.