Should the main Interledger UX use payment channels, on-ledger settlement, or hosted accounts?

Implementations and SDKs
, ,
1

ILP can be used with a number of different settlement arrangements. The flexibility is useful but makes it hard to explain to newcomers and unclear how we should recommend people use it or build integrations with new ledgers. @sharafian brought this up in the EOS Plugin thread and I think it’s a bigger conversation we need to have.

We could assume and build for any or all of the following:

  • Unconditional payment channels with bilateral credit limits of less than $1 (this is the model the XRP, ETH, and Lightning plugins use)
  • Post-transaction settlement using on-ledger transfers after an amount on the order of $10-1000 has been sent through ILP (this could be automated using an external “settlement engine”)
  • Monthly invoicing
  • Pre-funded hosted accounts

Should we pick one? Or say it depends on your use case and explain all of the possibilities?

If we direct new developers to get started using some downloadable or online tools, which experience should we point them to by default?

I would argue that in the future most of the end-user accounts will be pre-funded hosted ones and peered connectors will likely set specific credit limits or settle on a pre-defined schedule (daily or monthly). However, that doesn’t mean this is necessarily the right experience for the early days of the network.

What do you think?

1 Like
2
  • Unconditional payment channels with bilateral credit limits of less than $1 (this is the model the XRP, ETH, and Lightning plugins use)

Based on our experience so far, this has been a pain in the ass. The process of creating/destroying payment channels is unintuitive and expensive, plus it’s error prone because you need to maintain a payment channel in addition to your credit with your peer.

We could solve a lot of the UX problems around this by introducing a GUI similar to lightning’s GUI that lets you manage channels and see their capacities, but that’s a sizeable project. And I think for Interledger to get mainstream adoption, it’s important that people don’t have to manage their own keys or infrastructure.

  • Post-transaction settlement using on-ledger transfers after an amount on the order of $10-1000 has been sent through ILP (this could be automated using an external “settlement engine”)

I like this approach a lot, especially for receive-only arrangements. @wilsonianb brought this up in the context of Codius: When you’re receiving funds to a Codius node, you could configure your Interledger uplink with your address only (not your secret), so that you can watch for incoming payments. You could even receive money to an account that you don’t hold the keys for, like your exchange’s deposit address. I would 100% advocate we offer this arrangement for receive-only situations.

For sending, this is less than ideal. Pre-funding several dollars worth of liquidity with an untrusted upstream can be risky if you might not use all of it, and if you’re pre-funding only a few cents then fees become prohibative. Some networks like XRP could still have a good experience even with very low prefunding amounts, due to the low fees, but networks like ETH or BTC would be far too expensive.

  • Monthly invoicing

Coil has been using this in production for our relationship with Strata. It’s hard to get more efficient than this, but there’s also no code required so it’s almost not worth discussing. We should definitely document it as an option but there are a lot of arrangements where this wouldn’t be acceptable.

  • Pre-funded hosted accounts

We really have to offer this as an option, because not everyone will want to use cryptocurrency directly. XRPTipBot has done a great job with this already, but it would be cool if people could hook into their XRPTipBot account to directly use Interledger for sending/receiving.

Wallets that purely offer SPSP send/receive are good but they don’t help developers that much. For any non-technical users, though, I agree that this is only option.

I would argue that in the future most of the end-user accounts will be pre-funded hosted ones and peered connectors will likely set specific credit limits or settle on a pre-defined schedule (daily or monthly). However, that doesn’t mean this is necessarily the right experience for the early days of the network.

I think for early developers/users hosted accounts are the way to go even now. If we get the Codius network running it would help with that because it makes running a wallet less risky.

Proposal: Once XRPTipBot has sending functionality over SPSP, users could ask for XRP on twitter to get started on ILP (or deposit some themselves). Then they can withdraw that onto a hosted connector on Codius which keeps balances/payment pointers for users, but also offers raw BTP access. They can use a moneyd uplink to connect to that Codius connector and then develop on ILP.

This has the advantage that you never need the whole 25 XRP for a wallet. 0.1 XRP could be plenty to test out ILP. We could trim out some of those steps by having the moneyd uplink help you through the whole process, and we could trim out the whole Codius part if someone with a hosted wallet offered raw BTP access to their users. LMK what you think.

TL;DR: I really like hosted wallets

3 Likes
3

I agree, the hosted wallet model is hard to argue against and will serve as a great onramp to test ILP, plus benefits the Codius network.

A GUI similar to Lightning’s GUI is also a good solution to the UX problem with managing payment channels, so I think that’s something that should be explored as a secondary option.

2 Likes
4

So I think most of your first users (and biggest critics, as well as supporters) will be coming from the existing cryptocurrency community.

It’s important to have options because that’s where politics can become a problem. A default client needs to ship with UX studied defaults and should make it easy to self-host if so desired. But I do agree that most people would not want to host their own client and that pre-funded hosted accounts allow us to do a ton of interesting abstractions that you couldn’t do with money otherwise.

Part of this question also comes down to what are the main value adds for Interledger, specifically on the user side assume you provide all these options. Whichever defaults you pick really depends on the audience. Developers, crypto enthusiasts, infrastructure may want the freedom. Regular users will probably appreciate the abstractions. I think the ideal outcome is to have two different user experiences that optimize for those audiences. It’s definitely a lot of work, but unless you get rid of payment channels completely, I think you’ll have a divide between how people want to use this. We should be making use of payment channels as much as we can because these ledgers aren’t going to scale significant magnitudes without their networked variants, and we can’t do any form of micropayments if we don’t. But in order to do that, it comes with these compromises on the UX side. A good example of a company making the many right compromises on UX and hosted infrastructure is Keybase, so maybe we can learn something from them.

Someone will have to build a wallet (I’m thinking I’ll start this after I’m done with college :slight_smile: ) and unless you do a chain-based layer 3 like the Cosmos network or Polkadot, you can’t really do things differently in terms of interoperability, and I think this right now is the best we’ve got for value transfers. The golden ticket would be if there was some kind of breakthrough in payment channels that would allow us to not watch ledgers all the time just like layer 1s do.

Yes, this is 100% true. Mainstream adoption will require a ton of abstraction, and a product that makes sense. Additionally, there needs to be good key management practices on behalf of any connector that comes out (this would be a good reason to decouple the settlement engine to another service) so that all the complexity can be separated.

3 Likes
5

I think any opportunity to leave flexibility in the system should be considered. There are a LOT of varied use cases and it seems in the spirit of ILP to keep things pretty agnostic (Don’t enforce unnecessary standards) and flexible.

Whichever has the best documentation right now? I imagine there could be a whole section of finalized documentation thats eventually developed that will show the developer various possibilities and a few snippets so they can choose which works best for them.

I think about this a lot. Today’s average user (Outside of Cryptoland) is incapable of grasping the importance of key management. Even as a knowledgeable developer, I was complacent enough to become compromised and only gave the task of key management the attention it deserves after the breach. However, some users will have the desire to both assume complete responsibility for their keys AND they want to use an intuitive and simple app to accomplish this task. We have a lot of work to do, but that is our goal with Harbor. We want to enable the average human to responsibly manage their own accounts without relying on a third party for security of funds or the transaction. There are always going to be individuals that want to “Be their own bank”. That pool of individuals will grow if we continue to have world events that cause mass distrust of financial institutions by the general public.

For receive only, this seems to be about as simple and cheap as it can get. It also seems like you could have the inverse built and added to the same so it settle bidirectionally.

Finally, this seems like it would be the obvious implementation to use if you were building for an online merchant. Since there is a declared price the merchant wants to receive for their item, the settlement amount could be dynamically set to the item total. Buyer streams money into the recipients desired currency and a single TX settles to the merchant.

Some companies may not be able to afford the licensing to operate hosted wallets.

Working on it! :grin:

1 Like