W3C home > Mailing lists > Public > public-interledger@w3.org > April 2016

[b2b] Receiver-selected routing

From: Roger Bass <roger@traxiant.com>
Date: Fri, 1 Apr 2016 17:10:38 -0700
Message-ID: <CA+nC-XtODh1yf6jYQ+oG+ubiTmAkjyA8WBqTJw4YrHWp99ybTg@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>
In a previous email, I raised the notion of a new kind of payment
instrument that could settle across the Interledger network - or
alternatively, a legacy payment network. (This could be seen as an
Interledger failure mode, adding to its reliability and reach). That email
discussed some reasons why such a model might be important.

In framing this as a question for the community here, however, I realize I
should perhaps have framed this more narrowly to start with, focusing on
the technical questions I see arising. So here goes:

We've had some discussion of source-based and other routing. Is it
conceivable to have a destination-based and receiver-selected routing
model? The flow I envision would be something like this:

a) Payer P1 initiates a payment by means of its escrow on an originating
ledger L1
b) a token/uri T is generated on L1 for the Payee Pn to claim the payment
c) the payment token is transmitted to Pn through some secure channel
d) Pn (or its agent) executes some routing algorithm to determine if an ILP
path can be found to a ledger on which Pn has an account (and if the cost
of such a path is acceptable)
e) optionally, Pn may repeat the routing query for multiple ledgers on
which they have an account
f) if an acceptable path to Pn ledger L(n-1) is found, Pn "claims" the
payment from L1 by sending Payee's L(n-1) address, along with the
fully-specified path (perhaps by means of a call to the token/uri T)
g) L1 confirms that the escrowed payment has not already been claimed
h) if not, payment proceeds per the protocol as usual.

There are potentially some further important considerations not addressed
here: eg security / identity verification, especially as regards the
bootstrapping of a secure channel. But let's set those aside for now.

I'm not sure if there's a significant technical difference in the routing
algorithm implied here. However, this model does give the Payee the ability
to compare and select between alternative ledgers/networks that are
available to them, potentially even including legacy (non-ILP) networks. As
regards the Payee finding an ILP ledger with an available routing path from
L1, their choices could include the provisioning of an account on a new
ledger. This could help create an important viral adoption dynamic.


Received on Saturday, 2 April 2016 00:11:08 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 2 April 2016 00:11:08 UTC