Re: Roll call / intro - expand the scope of Interledger Protocol to beyond payment

> On Dec 3, 2015, at 11:07 AM, Thomas Hardjono <hardjono@mit.edu> wrote:
> 
> So perhaps this WG should focus on (i) but all the while in the back of our minds remember non-currency cases (ii).

I completely understand about focus and I certainly don’t want to take us off into the weeds. My only goal is to point out how some concepts which seem different, are already solvable with escrow based ledgers using the same API as a currency system.

> On Dec 3, 2015, at 11:28 AM, Ryan Fugger <arv@ryanfugger.com> wrote:
> 
> I guess that's a generalization of Bob's example where the goods to be delivered are tokenized into an ILP ledger, but it could expand to be much broader, with notaries connected to shipping companies, as one example.


In fact I did consider this very case. Bear with this short journey into the weeds. My goal is to introduce a clever device that keeps us out of them in the future…

Every currency payment is part of a larger circular business transaction. If a customer Alice is buying a product from a merchant Bob, then half the transaction is taking currency from Alice and paying it to Bob. The other half of the transaction is taking the product from Bob and delivering it to Alice. Both halves are equally important to the deal.

UPS is a package delivery company in the US. As Ryan points out, you can conceptualize UPS as a type of escrow based ledger. In ILP terms, Alice’s payment goes into escrow with her bank as part of her “prepare” step. Bob could analogously give the product to UPS as part of his “prepare” step. Alice “signing” the UPS delivery receipt and UPS “notarizing” it, then becomes the “execution" condition that finalizes the payment transfer(s).

…yes, we could wander lost in these weeds forever…


What is worth realizing, is that while we often think of the delivery half of a business transaction as happening after the payment, the delivery must always negotiated before the payment can even be determined. 

As such, we can encapsulate the details of the delivery half of the transaction into a single contract document. Alice and Bob must agree on the terms of this contract before the payment can take place. But otherwise, this contract can be completely opaque to the payment half of the transaction. In fact, you can simply hash the contract and use that as a proxy for all the delivery side details.

This contract hash can than be signed (as the ILP payment “receipt") to both trigger payment execution and to signify agreement to the contract’s delivery terms.


Bob Way
Software Engineer | Ripple
bob@ripple.com <mailto:ben@ripple.com> | ripple.com <http://ripple.com/>






> On Dec 3, 2015, at 11:28 AM, Ryan Fugger <arv@ryanfugger.com> wrote:
> 
> Good example, Bob.  That definitely shows how flexible ILP should be.  Can we think of examples that actually do change things from an ILP perspective?  *Those* are the ones I think we really need to discuss how to handle, or at least make an informed decision not to handle at this time...
> 
> What about payment reversibility?  Maybe that's something we should talk about, at least to make sure that whatever arrangements ledgers and/or connectors want to make for reversibility at a level above ILP's settlement layer are possible.
> 
> We might also talk about scenarios where it might be useful to have the transaction notaries trigger release of escrowed funds only once the other half of the transaction (ie, delivery of goods or services) has been successfully completed, and whether that would have any impact on the ILP design.  I guess that's a generalization of Bob's example where the goods to be delivered are tokenized into an ILP ledger, but it could expand to be much broader, with notaries connected to shipping companies, as one example.
> 
> What else?
> 
> On Thu, Dec 3, 2015 at 10:31 AM, Bob Way <bob@ripple.com <mailto:bob@ripple.com>> wrote:
> I’d like to give a big +1 to discussing this.
> 
> Payments don’t really happen in a vacuum. If Alice send money to Bob, then she did so for a reason. 
> Bob clearly benefited from receiving the payment. Alice clearly incurred cost by sending the payment.
> What generally goes unmentioned is that Alice likely received a benefit out-of-band from the traditional payment system.
> Likewise, Bob likely incurred some cost/expense (maybe it was goods sold) out-of-band as well.
> 
> In many types of transactions, it is possible to include these formerly out-of-band transactions into a single ILP “circular” payment. Stock transfer and digital goods sales spring immediately to mind.
> 
> So as example, Alice has USD and wants to own a share of AAPL stock. A clever bit of pathfinding could create a circular ILP payment that 1) debited Alice’s USD on her bank’s ledger, and as part of the same transaction, 2) credited Alice’s account on the AAPL stock custodian’s ledger. To make this possible some third party (Bob) is essentially swapping with Alice. Bob’s bank account gets credited, and his stock accounted debited.
> 
> Nothing really changes from an ILP perspective. Both the core banking systems and stock custodian’s systems are ILP “ledgers”. Both Alice and Bob in effect serve as ILP “connectors”.
> 
> Bob Way
> Software Engineer | Ripple
> bob@ripple.com <mailto:ben@ripple.com> | ripple.com <http://ripple.com/>
> 
> 
> 
> 
> 
> 
>> On Dec 2, 2015, at 8:27 PM, Nitin Gaur <ngaur@us.ibm.com <mailto:ngaur@us.ibm.com>> wrote:
>> 
>> Hello Folks
>>  My name is Nitin Gaur, I serve as a Director of Blockchain Labs  @IBM.
>> 
>> I wanted to float an idea prior to our first cal, where we expand the scope of Interledger Protocol to beyond payments.  The idea is to ensure that we are aware and linking payment activity to other business functions.  Such as Mortgage initialization, Mortgage securitzation, Car loan payment etc. The idea being to explore how blockchain  can be employed in conjunction with other business activity in  Financial services sector. 
>> 
>> This will also broader the horizon and applicability..linking payment to broader blockchain ecosystem.
>> 
>> Thoughts?
>> 
>> N
>> 
>> :)
>> Nitin Gaur
>> IBM Blockchain Labs
>> 512-789-5300 <tel:512-789-5300>
>> 
>> -----Forwarded by Nitin Gaur/Austin/IBM on 12/02/2015 10:21PM -----
>> 
>> From: Bob Way <bob@ripple.com <mailto:bob@ripple.com>>
>> Date: 29 October 2015 at 20:52
>> Subject: Re: Roll call / intro
>> To: "public-interledger@w3.org <mailto:public-interledger@w3.org>" <public-interledger@w3.org <mailto:public-interledger@w3.org>>
>> 
>> 
>> Hi all. I’m Bob Way. I work with Stefan, Evan and Adrian on the interledger team at Ripple.
>> 
>> I ran across Bitcoin pretty early and became a fanboy of the cryptocurrency concept. A couple years later I discovered OpenCoin’s Ripple announcement and became intrigued with the possibilities of transacting in fiat currencies within the framework of a cryptocurrency system.
>> 
>> It was during my pre-employment research into OpenCoin’s Ripple system that I discovered Ryan Fugger’s “classic" Ripple Pay system. In fact, I credit my grasp of the “rippling” concept to some patient tutoring from members of Ryan’s community. (Great to meet you Ryan!)
>> 
>> Now after two and a half years at Ripple, I’m ecstatic about establishing ILP as a global open standard supporting all types of transactions. I believe ILP can optimize the benefits of social credit, cryptocurrency, and traditional finance by connecting them all into an interoperable web of value.
>> 
>> Bob Way
>> Software Engineer | Ripple
>> bob@ripple.com <mailto:ben@ripple.com> | ripple.com <http://ripple.com/>
>> 
>> 
>> 
> 
>