Re: [b2b] Receiver-selected routing

Stefan,

Thanks for your thoughtful reply. Several interesting points you make, to
which I'll comment or respond below.

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

I think I agree. Application level seems simpler, to start with at least. I
see two sub-cases there. That said, as I wrote those two, I thought of a
possible reason to consider protocol-level pull payment implementation -
see (3) below.

1) Secure Channel. We supposed here the existence of a secure channel
between Payer and Payee (again, leaving aside for now questions of
bootstrapping that channel). The pull payment initiation message could
simply be sent back through that channel, which might have some security
benefits.

2) Payer Agent. The Payee (or their agent) could indeed interact directly
as described with the Payer's designated agent to initiate the pull payment
- where such agent could indeed be L1. Any such agent would certainly need
to be always online, with high reliability. This might apply as part of a
bootstrap scenario, before setup of the secure channel. Such a model does
exist in a corresponding interaction pattern for card-based B2B payments,
FWIW. (I know I said we need the secure channel to exist - need to revisit
the bootstrap scenario more fully later, notably from email).

3) Protocol Layer Pull Payments. This would be required if we wanted to
enable the Payee to ONLY interact with their designated ledger/processor to
collect such payments. Two reasons to consider this: one, as you say
Stefan, is in support of recurring debit payments. But secondly, and more
broadly - this precisely the process flow for some mainstream payment
processes that ILP might aim to replace. Specifically: checks - which Payee
presents to their bank for deposit. Or card numbers, "presented" by Payee
to their merchant solution provider for processing/capture. It seems fairly
obvious that an ILP clearing option would be less disruptive to existing
processes if it supported the same model. (We could get into more detail on
this if necessary).

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

This "routing tags" idea is very interesting. However, I suspect this might
be even more powerful in the form of *sender* tags for the reverse routing
scenario. Senders, after all, are the ones who control payment initiation.
I'm wondering even to what extent the model you propose could be
generalized to encompass representations of legacy payment routing options.

Roger
On Apr 1, 2016 9:12 PM, "Stefan Thomas" <stefan@ripple.com> wrote:

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