Re: [b2b] Receiver-selected routing

First off, I really appreciate the clearly laid out, step-by-step flow.
That is very helpful in terms of understanding what you're talking about.

What immediately sticks out to me is that this use case seems in a similar
class as pull payments. E.g. I give a token to the New York Times and now
they are allowed to withdraw my monthly subscription fee out of my account
every month.

This is a very common use case (esp. for subscriptions, pay-as-you-go
models etc.), so we will definitely have to support it in some way.

> I'm not sure if there's a significant technical difference in the routing
algorithm implied here.

What you describe does require a routing algorithm which works both forward
and in reverse, but that seems doable. The routing problem is generally
very symmetric.

Where I do see some challenges is regarding "long-distance" communication:

We are assuming that users in ILP can talk to their neighbors: I can talk
to my ledger, you can talk to yours, a connector can talk to the ledgers
that it's providing liquidity between. We are also assuming the sender and
recipient have some out-of-band channel which is use case specific.

However, one thing we are specifically not requiring in for users to talk
to *other people's* ledgers. For instance, you might be using Bitcoin as
your ledger and I might have no idea how to talk the Bitcoin protocol.

Ledgers generally are the systems that already exist and connectors as well
as application-level protocols are generally the systems that we're adding.
So it's much easier to add features to connectors than to ledgers.

With that in mind, I see two basic options: You can defer pull payments to
the application layer and simply let the recipient make a request to the
sender's server, triggering a regular push payment.

Or you could aim for a more elaborate solution utilizing the connector
chain to perform some pull flow.

Doing it on the application level is obviously simpler and I'm not aware of
any strong reasons not to do it that way.

One common objection is that the sender may not be online always, but
that's more of a misconception due to jargon. When we talk about the
sender, we talk about the ILP concept of a sender, not necessarily the user
who is actually sending the money. The server that performs the ILP sender
function could well be the same server that also acts as the ledger. For
instance, our demo deployment red.ilpdemo.org [1] uses one server to run
both five-bells-wallet (which acts as sender and recipient in the ILP
sense) and five-bells-ledger (which acts as ledger in the ILP sense.)

So now the question is whether that's enough to meet your use case. You
mention:

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

In our current view on routing (proper write-up coming soon), recipients
would provide routing tags that describe how to get from a well-known
ledger to them. They can provide multiple such tags in order to account for
the fact that there may be multiple connections. (This was a major omission
in IP, where TCP connections are with a single IP address, making it
difficult to seamlessly utilize multiple Internet connections at once.)

In other words, we're trying to provide a way that even sender-driven
routing would be able to take advantage of the recipient's knowledge about
their local environment.

[1] Can be found at https://red.ilpdemo.org and https://blue.ilpdemo.org

On Fri, Apr 1, 2016 at 5:10 PM, Roger Bass <roger@traxiant.com> wrote:

> 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.
>
> Thoughts?
>
> Roger
>