Re: HTTP 402 in use

Corda implements some basic ideas I've expressed, but Corda isn't a
protocol.  A protocol defines the data structure.

For example, John gave Sally a bag of apples, but Sally hasn't sent John
$10 yet:
<transaction>
  <promise>
    <promissor>
      john@email.com
    </promissor>
    <promissee>
      sally@email.com
    </promisee>
    <description>
      bag of apples
    </description>
    <status>Delivered</status>
  </promise>
  <promise>
    <promissor>
      sally@email.com
    </promissor>
    <promissee>
      john@email.com
    </promissee>
    <description>
      $10
    </description>
  </promise>
  <status>Delivering</status>
</transaction>


That's the protocol.




On 28 Mar BE 2561, at 5:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

@Adnrew: You should look at how states and agreements work in Corda.
The model is similar to what you describe

On 28 March 2018 at 04:02, Andrew Bransford Brown <andrewbb@gmail.com>
wrote:

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