- 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.
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