18q1 requirements

[michielbdejong]

Amundsen is the Interledger Testnet Bootstrap Server, you can connect to it if you don't know anybody else who runs a testnet connector. As such, it has a big influence on what protocols and practices we consider current and what we consider deprecated. Its api is versioned quarterly, so this quarter we define what the 18q1 api end-point should offer.

When the Amundsen project was started, the reference stack (i.e. ilp-connector and its plugin collection) didn't support BTP yet (then still called CLP) and it actually never supported the Vouch protocol, so these were implemented from scratch in this repo. The reference stack now caught up with the BTP spec, and we no longer need the Vouch protocol because we will not be doing on-ledger escrow anymore (see https://www.slideshare.net/Interledger/34c3-interledger-presentation-background-streaming-payments-and-implications/57)

Requirements that still stand for 18q1:

• Run an ilp-connector instance, with the following ilp-plu-pay-cha-fra instances:
  • ilp-plugin-xrp-paychan
  • ilp-plugin-lightning
  • (once it's ready) ilp-plugin-eth-paychan
• A WebSocket server with automated LetsEncrypt registration/renewal
• Call plugin.addSocket on the right plugin each time someone connects to the WebSocket server.
• Run instances of btcd and lnd and configure ilp-plugin-lightning with a filled wallet
• Configure ilp-plugin-xrp-paychan with a filled wallet
• Run an instance of geth and configure ilp-plugin-eth-paychan with a filled wallet
• Provide a landing page with explanation and links to how to use Amundsen

Some may say that running a WebSocket server with automated LetsEncrypt registration/renewal in front of the various plugin instances is not even necessary. An alternative would be to have each plugin run on a different port, and reboot the server each time the LetsEncrypt cert expires. If people prefer that, then we can discuss that in a separate issue.

So Amundsen is like ilp-kit, but stripped down to just the minimal server to wrap ilp-connector in.

Who is interested in contributing to this project? Is anybody already doing a similar project? If so, we should join efforts! :)

[emschwartz]

Another question I would have is: are there compelling reasons for the testnet bootstrap server to run different software than the reference stack (ilp-connector)? If so, is the ilp-connector missing features that should be added?

[michielbdejong]

I think the scope of ilp-connector excludes features like LetsEncrypt certs, so a connector admin will always need some sort of server to embed the ilp-connector module in?

[emschwartz]

Interesting. If that would be needed for anyone running a connector maybe it's not outside the scope? If it is outside the scope of ilp-connector, are you envisioning making Amundsen include and use the ilp-connector (as opposed to it reimplementing connector functionality with some tweaks)?

Are there other any other things on the list of differences?

[michielbdejong]

are you envisioning making Amundsen include and use the ilp-connector

yes

[michielbdejong]

Are there other any other things on the list of differences?

See #18 (comment)

[michielbdejong]

Amundsen is just a WebSocket server, in front of ilp-connector's ilp-plu-pa-cha-fra instances. :)

[dappelt]

• Call plugin.addSocket on the right plugin each time someone connects to the WebSocket server.

As just discussed during our call, to determine what the "right" plugin for a given user is, you could require a user to explicitly register. That way Amundsen can throw an error if a user is accidentally connecting to the wrong plugin endpoint (e.g. /ltc instead of /xrp)

[michielbdejong]

Yes, I created #19 about that