- From: Andrew Bransford Brown <andrewbb@gmail.com>
- Date: Tue, 27 Mar 2018 00:16:08 +0700
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments <public-webpayments@w3.org>
Yes, I agree with most of that. A payment is one of the "Deliver" messages in the 6 events of a contract. On Tue, Mar 27, 2018 at 12:04 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 26 March 2018 at 18:47, Andrew Bransford Brown <andrewbb@gmail.com> > wrote: >> >> HTTP message composition must be sufficiently granular to handle all >> use cases. >> >> Here are 6 events in a contract, from initial offer to delivery: >> [1] John Offer $1 >> [2] John Terms Water >> [3] Mary Agree (becomes a contract) >> [4] Mary Deliver Water >> [5] John Deliver $1 >> [6] End transaction >> >> Headers to describe [1] John's Offer: >> Transaction-ID: 123 >> Commerce-ID: John >> Event-Type: Offer >> Description: $1 >> Time-Stamp: 2018-03-26T23:40:30 >> >> Headers to describe [2] John's Terms: >> Transaction-ID: 123 >> Commerce-ID: John >> Event-Type: Terms >> Description: Water >> Time-Stamp: 2018-03-26T23:40:31 >> >> etc. >> >> Each is its own HTTP message? > > > Given the complexity that arises, it seems a little unwieldy to stuff all of > this information in headers. > > Similarly to put this information in the body also can be problematic > because how do clients then cache the content, when it is changing and has > its own state diagram, for any given resource. > > And putting things like a payment request in the body (although bonus marks > for having the right content type) might not allow a human readable message > > Some quite tricky design trade offs > > A possible solution here might be for the resource yielding a 402 to > redirect the client to a URI from which it can learn more and negotiate a > payment. > > Then have a set of standard messages that can be used to pay e.g. what is > the cost, where do I send the money, how do I send it etc. > >> >> >> >> On Mon, Mar 26, 2018 at 10:10 PM, Melvin Carvalho >> <melvincarvalho@gmail.com> wrote: >> > >> > >> > On 26 March 2018 at 16:31, Adrian Hope-Bailie <adrian@hopebailie.com> >> > wrote: >> >> >> >> Pity it only works on Lightning though... Would be nice to get some >> >> collaboration on something that works across any payment network >> >> >> >> https://tools.ietf.org/html/draft-hope-bailie-http-payments-00 >> >> https://interledger.org/rfcs/0014-http-ilp/ >> >> >> >> >> >> https://medium.com/interledger-blog/http-ilp-paid-api-calls-with-interledger-fda53643a2eb >> > >> > >> > Thanks for the pointers. >> > >> > I'm a fan of the work on lightning, however the 402 response itself >> > doesnt >> > seem to be lightning specific >> > >> > So it seems that the main difference is that this work uses >> > >> > X-Token >> > >> > vs the draft using >> > >> > Pay-Token >> > >> > And the body contains bolt11 payment request >> > >> > Both approaches seem reasonable? >> > >> > Perhaps the draft could look at a variety of implementations and use >> > cases. >> > >> >> >> >> >> >> On 26 March 2018 at 13:15, Melvin Carvalho <melvincarvalho@gmail.com> >> >> wrote: >> >>> >> >>> Very cool use of HTTP 402 -- Payment Required -- in the paypercall >> >>> lightning network app >> >>> >> >>> https://github.com/ElementsProject/paypercall#paying-for-api-calls >> >> >> >> >> > > >
Received on Monday, 26 March 2018 17:16:32 UTC