Handle HTTP 402 payment required responses

[bumi]

I am wondering what your thoughts are on trying to handle HTTP 402 responses to request payments: If a server responds with a 402 HTTP status and a lightning invoice the extension could prompt the user to confirm the payment and "refresh" the page with a proof of payment. (if auto-payments are enabled for the domain the payment could be done automatically.)

From what I've seen so far it might be tricky to get this working with the available extensions APIs, but I've looked into the chrome.webRequest.onBeforeSendHeaders which allows to check the response headers and to block/redirect the request... maybe it can somehow be hacked.

I've lately experimented with a similar flow for API requests (blog post) also ln-paywall is pretty cool.

Would love to see this to pay for content :)

[wbobeirne]

This is a really interesting concept! The extension webRequest API could definitely jump in here, but I feel like it would result in a much better user experience if the application handled the 402 error, and presented the user with a BOLT-11 link to make the payment (or a webln.sendPayment call to trigger the payment prompt.)

I'm definitely open to this though, if there comes to be a standard around using the 402 response (ln-paywall looks promising.) However, I'm sure everyone will implement it slightly differently (plaintext bolt-11 string, JSON object with the bolt-11 string as a key, etc.)

[bumi]

ahhh...hmmm. so you mean rendering the 402 as a page with a BOLT-11 link that triggers the payment? that's probably easier to implement. my motivation somehow is to make it as frictionless as possible to pay/tip for content - ideally with hardly any user interaction (on trusted sites).

regarding the standard: yep, indeed that's a problem. my ruby implementation and the go implementation are compatible. I guess it is the time right now to experiment with what works best and encourage adoption.

Also have you looked at the W3C payment request API? (I think @cdecker is part of the working group) - that's a bit of a different topic/issue though.

[JASchilz]

Another idea for placing a Bolt-11 invoice in a 402 response: in a header.

A header would require the least coupling between client and server. If the invoice is in a header rather than the body, then the client doesn't have to know to look for the invoice under a particular JSON key, or inside of an XML tag with a particular ID, etc.

On the other hand, defining a new header or using an existing one might be stepping on the toes of the HTTP protocol group.

[wbobeirne]

It looks like that's exactly how ln-paywall functions: https://github.com/philippgille/ln-paywall/blob/master/README.md#how-it-works

[JASchilz]

If I'm reading it correctly, it looks like the client returns the payment preimage in a header, but the payment request itself is in the body. But putting it alone in the body seems like a fairly de-coupled solution as well!

[bumi]

yep, ln-paywall and rack-lightning are both using the body for the lightning invoice (content type application/vnd.lightning.bolt11)

I like the idea of using a header. The content type then can be HTML and a normal page can be returned for browsers without the extension. The extension could listen for HTTP 402 responses and prompt the user to pay the payment request from the header.