W3C home > Mailing lists > Public > public-interledger@w3.org > July 2017

testnet entry/exit nodes and client-side receivers

From: Michiel de Jong <michiel@unhosted.org>
Date: Tue, 18 Jul 2017 10:45:54 +0200
Message-ID: <CA+aD3u1yDtD_kewD==nrx+dKrBEdvz_zpRNWYss55bOLMhAHbA@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>
Hi all,

I wanted to open up a discussion to you, which some of us were having a few
days ago, but for that I first need to provide some background:

As discussed in the last community call, we started building a testnet. You
can now choose whether you want your node's home ledger to be part of the
live network (prefix `g.`) or of the testnet (prefix `test.`). We ask
everybody who runs a connector to situate their connector firmly on one
side of that divide, so either you connect only between `g.` ledgers, or
you connect only between `test.` ledgers. We'll probably add a feature in
ilp-kit to make it impossible to violate that rule from the admin UI, but
if you run a home-grown connector implementation, or edit your server
config via ssh, then please apply that rule manually.

*Entry/exit nodes*
You may have heard about the 'seven ledger demo' which took place at the
last Interledger workshop.[1] These new interledger plugins allow two
things: first, they allow two peers to use a ledger-backed HTLA. [2] But
they also allow a connector to connect someone's personal ledger to one of
the crypto-currency ledgers, as such! So not just one-to-one, but
one-to-many (exit) or many-to-one (entry). However, doing this on the live
net would mean you need to be careful who pays via your connector from a
personal ledger to a crypto-currency (exit node) and who pays from a
crypto-currency to a personal ledger (entry node). Running such a connector
could have different legal implications in different countries. That's why
it's easier for us as a community of researchers and open source
enthusiasts to add such entry/exit nodes to the Interledger testnet,
connecting the various testnets of various crypto-currencies. That way, we
create a 'testnet of testnets'. :)

*Connector discovery*
On a five-bells ledger, connectors can be discovered by requesting the list
of recommended connectors from the ledger. Blockchains generally don't
provide this feature. Therefore, I'll soon add a list of testnet wallet
addresses for entry nodes per crypto-currency on https://connectorland. [3]
You can then use an Interledger client like [4] to prepare an on-ledger
payment from your own testnet wallet to the entry node's wallet, and at the
same time send an rpc call to the entry node to initiate the Interledger
payment to any destination.

*Destination discovery*
For addressing destinations, ilp-kit relies heavily on spsp (the
user@host.com address format that is translated to an interledger address +
a uniquely assigned shared secret). This requires the receiver to run an
spsp server (like [5] or [6]) and then identify as user@spsp-server.com.
They can then specify their wallet address at a crypto-currency ledger as
their Interledger address, which would mean any payment to them would reach
that ledger via an exit node.

*My point - finally ;)*
A different identity system, which does not require the receiver to run a
server, may be more appropriate for paying out over exit nodes.

I like the WebFinger part of spsp, especially because it's an optional
extra layer, but IMHO the requirement for the spsp end-point to be
publically addressable is a downside of spsp. Why not just add an
Interledger address + a public key into the receiver's WebFinger record,
and bootstrap things from there?

Then, the receiver could run their software client-side (just on their
laptop, publishing just that static public key to their personal website),
and we can decouple the tight link which currently exists between
interledger nodes and internet servers.




[3] https://github.com/interledger/connector.land/issues/20

[4] https://github.com/interledgerjs/ilp

[5] https://github.com/interledgerjs/ilp-kit

[6] https://github.com/emschwartz/cicada
Received on Tuesday, 18 July 2017 08:46:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:08 UTC