Should the testnet of testnets use on-ledger escrow, payment channels, or trustlines?

[emschwartz]

I think the goals of the Interledger Testnet of Testnets (IToT) are:

1. Provide a permanently deployed Interledger connector that developers can use for demos and testing client software (including implementations in other languages) or other Interledger applications against
2. Show newcomers to the project that Interledger makes different networks interoperable
3. Show newcomers to the project how awesome payments could be

To these ends, I see two main things that are worth showing off:

1. That anyone can send a payment from any of the supported testnets to any other one using Interledger, and they can see the ledger transfers going through on the block explorers of the respective cryptocurrencies
2. Payments going at speeds we consider realistic for the proper Interledger
3. What the developer experience is using Interledger

On-Ledger IToT Experience

1. Go to a website and select what currency you want to send from and to (maybe generate credentials, or just give everyone the same credentials and hope no one cleans the accounts out of testnet money)
2. Click Send and have some visualization of the payment going through or an explanation of what's happening
3. Have links to the various component transfers to see that the payment really went across both ledgers, and maybe some things like the fact that the execution condition was the same or the packet was relayed across both
4. Show a note that explains how this is kind of slow because these ledgers are slow, so for a realistic experience you wouldn't send every single payment over the ledger but rather would use payment channels or trustlines, which brings us to the next experience

Payment Channels and Trustlines Experience

1. Same type of website as before (maybe even just a different tab on that website) where you can select what currency you want to go to/from
2. Click Send and it goes through pretty much instantly
3. Explain that the payment went through payment channels or trustlines, which are a kind of virtual shared account that are enforced by or settled on a ledger and that can be updated instantaneously

Developer Tools Experience

1. Explain that the payments you sent in the other experiences were using the Javascript client library in the browser, link to that, and maybe show some examples of how you can use it (or the code that was actually used on the website)
2. Link to implementations in other languages

[diminator]

(maybe generate credentials, or just give everyone the same credentials and hope no one cleans the accounts out of testnet money)

This would be the easiest to set up, but maybe we push the complexity of draining the accounts at the interfaucet? But it might give us also an historical overview of other testnet transfers?

[diminator]

Have links to the various component transfers to see that the payment really went across both ledgers, and maybe some things like the fact that the execution condition was the same or the packet was relayed across both

what if we could visually illustrate how the transfer relates to the ILP packet? Maybe useful for devtools?

[diminator]

Same type of website as before (maybe even just a different tab on that website)

or maybe just a "speed switch" (or throttle)

[diminator]

other experiences were using the Javascript client library in the browser, link to that, and maybe show some examples of how you can use it (or the code that was actually used on the website)

maybe we can make that a bit interactive - a code snippet with input fields (eg notes), yielding different ILP packets

[michielbdejong]

I really like this idea! The way I would break down the IToT effort is basically:

1. design a versioned protocol stack for it -> done
2. set up a bootstrap node -> sort of done, although: a. it's not very stable yet b. only supports XRP, ETH, and BTP so far c. doesn't do exchange rates and limits on amounts yet, not really tested against vandalism d. we will want to refactor it to use the plugin-framework, once that includes a connection factory e. we want to move it to Ripple infrastructure, once available
3. set up an interfaucet -> sort of done, although: a. it's not very stable yet b. the feedback might be nicely visual, but it's not very verbose yet c. doesn't do limits on amounts yet, not really tested against vandalism d. we will want to refactor it to use the plugin-framework (don't need connection factory here) e. we want to move it to Ripple infrastructure, once available
4. set up several cool demos that show off how Interledger works across blockchains
5. provide tutorials and tools that allow developers to build stuff without having to come to https://gitter.im/interledger/testnet-of-testnets for all their questions

This proposal is a great description of point 4., I think!

Given that I'm about to take parental leave, this week is probably not a good time for me to take on big new projects; I should probably focus on fixing small issues in the existing stuff now, and leave point 4. for my Q4 goals? @emschwartz let's discuss that planning in our 1:1 today! :)

[michielbdejong]

more exact plan for the tutorials, as discussed:

1. xrp -> eth (using wallets whose keys we include in the tutorial, and that live on Amundsen's geth)
2. faster (show off BTP)
3. build app (show how people can ILP-enable their web app or web store)
4. host it (walk through how to actually run all of this code yourself)

[emschwartz]

Okay, yet another perspective on this:

@sharafian brought up the point that no one is really using Bitcoin or Ethereum for payments today. That is due to the slowness, the fees, the lack of acceptance, and the fact that many people are speculating on the price going up. The argument then is that we shouldn't bother trying to integrate them directly if those systems aren't really built for payments and they're too slow and expensive to make for a good Interledger payment experience.

Instead of doing BTC or ETH escrow, the argument would be that we should integrate the Lightning testnet (they have a public faucet here) into the testnet of testnets.

We did an integration with lightning before but we could work on improving it so that the Interledger condition is the same as the lightning condition. The main thing we would need for that would be to update @BitfuryLightning's lnd branch that emitted events for incoming transfers that don't correspond to stored invoices. To do on the livenet we'd need the channel-close-after-30-second idea to be implemented first to bring the "effective timeout" down to a matter of seconds, but we could do it on the testnet without that.

So maybe the testnet of testnets would just have XRP (escrow?), Lightning, and maybe USD-denominated BTP. Thoughts?

[michielbdejong]

Yes, adding lightning has always been the plan, right? I wasn't aware of the lightning-over-bitcoin-testnet faucet yet, that's cool! Great if we can speed up adding lightning.

I'm not sure why we would want to remove ETH though, I liked our idea of just having a public provider with some test accounts that everybody is allowed to play with (put the keys in the tutorial text), which makes it easy to get started.

[michielbdejong]

But now that we will (soon?) build example apps where you can pay for something using interledger-over-xrp-escrow (not even going through a connector), I think we will discover a lot of new problems to solve, like things that don't work nicely yet from the user's perspectives, that will be of higher priority.

[sharafian]

I'm not sure why we would want to remove ETH though

There's no reason to remove ETH from the testnet, but it's currently pretty risky for a connector to use on any main-net. It costs a few dollars worth of ether to set up an escrow with the contract, and while optimizations could get that down it would still be more than a connector wants to put up for free. The rollback fee idea might be able to address that in the future, though

[michielbdejong]

now that we will (soon?) build example apps where you can pay for something using interledger-over-xrp-escrow (not even going through a connector), I think we will discover a lot of new problems to solve, like things that don't work nicely yet from the user's perspectives, that will be of higher priority.

Created https://github.com/interledger/tutorials/pull/1, curious what people think of it! :)

[michielbdejong]

Since the new tutorials are starting to take shape now, we can separate the 'tutorials effort' from the 'testnet effort' (the first relies on the second, but the testnet will be useful for more than just supporting the tutorial users during their study).

The 'testnet effort' can be further split into Amundsen work, Interfaucet work, and testnet documentation.

For the 'tutorials effort', we can maybe continue this discussion in https://github.com/interledger/tutorials/issues/3?

[michielbdejong]

This issue was split up into four parts, see previous comment