Re: Zero Click Bitcoin Micropayments using HTTP 402

You're taking past one another. Let me clear a few things, having read this
whole back and forth.

- This would be more than a couple lines of js.

- The code would need to intercept navigation and present a payment screen.
That could be done by a proxy or a browser extension or as built in browser
behavior. For a proof of concept, any would be acceptable.

- A Chrome extension is a working demonstration of something which could be
built into a browser, and is more reasonable for many people to test an
idea than installing a fork of a browser. It's closer to the right
separation of entities than having a proxy. No one should be concerned that
a proof of concept starts this way. Everyone should understand that
whatever UI and interaction is written into such an extension is a stand in
for a future built in feature.

- 402 is the clear choice for the status code of the initial response
exactly because it has largely been ignored. There are no *conflicting*
semantics already defined, and that's what really matters.

- 402 is only sufficient to say that payment is required, whereas accessing
paid content involves also making the payment and then requesting the
content with proof of payment. Melvin described this proof as given by
certificates, but didn't describe the payment or the mechanism by which
that payment changes the balance associated with the certificate. All that
needs to be specified still, but that doesn't mean 402 is wrong.

Interface guidelines are needed for the agent, as well as the protocol for
making the payment and making the authenticated access thereafter.

But let that come later.


Anyway, this idea won't go anywhere (in this context NB...) until a proper
specification is presented.  Based on two years experience with this forum
I don't think there will be such a thing but nobody would be more happy
than I if I was proven wrong :-)


 I would encourage people to follow through with demonstrations and
implementations and worry about spec writing later.

A mailing list is a fine place for informal collaboration and design.
Proposals need not come in the form of entity diagrams and specifications.
If something isn't clear, work together to clarify. No need to get mired in
spec writing before even trying to implement a prototype.

I hope that wasn't too confrontational and that it helps move the
conversation forward.