-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle HTTP 402 payment required responses #46
Comments
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 I'm definitely open to this though, if there comes to be a standard around using the 402 response ( |
ahhh...hmmm. so you mean rendering the 402 as a page with a BOLT-11 link that triggers the payment? 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. |
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. |
It looks like that's exactly how ln-paywall functions: https://github.com/philippgille/ln-paywall/blob/master/README.md#how-it-works |
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! |
yep, ln-paywall and rack-lightning are both using the body for the lightning invoice (content type 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. |
…r-dom-5.1.5 Upgrade @types/react-router-dom: 4.3.5 → 5.1.5 (major)
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 :)
The text was updated successfully, but these errors were encountered: