- From: Andrew Bransford Brown <andrewbb@gmail.com>
- Date: Wed, 28 Mar 2018 09:02:22 +0700
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments <public-webpayments@w3.org>
A contract is a document. It is composed over time as participants add elements/events (Offer, Terms, Agreement, Deliver, Notice, etc.) So HTTP PUT can construct the contract. On Wed, Mar 28, 2018 at 3:39 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 27 March 2018 at 22:28, Andrew Brown <andrewbb@gmail.com> wrote: >> >> 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. > > > IMHO, the web scales really well when one document does one thing. > > For example a document that contains content, but has a challenge > > Or a document that has payment information, then leads you to a content link > > When mixing these two workflows, it's more difficult for clients to track > and cache previous bodies > > To my mind when getting a 402, it's saying -- there's content here (e.g. a > movie) -- but you need a payment > > It would be a nice separation of concerns if the negotiation of a payment, > especially if XML or JSON or RDF type documents are going to be parsed, > happened on another page. Perhaps an exception would be very trivial work > flows, but even in that case there is danger of a slippery slope. > > Nothing is really prohibited on the web, but in my head a clean design would > be. > > - Content on a page > - 402 if you need to pay > - If you need to pay, direct the user agent to some kind of payment API or > service > > I could be wrong on a number of points above, and appreciate there are > numerous ways to model this > >> >> >> >> >> > 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 Wednesday, 28 March 2018 02:03:04 UTC