- From: Andrew Brown <andrewbb@gmail.com>
- Date: Wed, 28 Mar 2018 03:28:40 +0700
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments <public-webpayments@w3.org>
Melvin and Adrian: We could put an xml document in the message body, and put the next event in the message header. Xml document - describes the contract and current status. Message header - next event to be added to the xml document. > On 27 Mar BE 2561, at 12:16 AM, Andrew Bransford Brown <andrewbb@gmail.com> wrote: > > 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 Tuesday, 27 March 2018 20:29:12 UTC