Re: HTTP 402 in use

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