t-bast
commented
5 years ago Would like to hear if people feel that this belongs at the node level, or if it should only be facilitated by layers on top of nodes.
That was exactly what I was thinking while reading this. I think that this is very useful, but should probably not be done at the Lightning node layer. There were some discussions on the mailing list concerning the creation of a "Lightning App Specifications" repository to centralize encoding choices for interoperable applications building on top of Lightning, maybe this proposal makes more sense there?
wbobeirne
joostjager
eupn
nicolasburtey
dr-orlovsky
Description
To further enable a better user experience and open up more use cases for Lightning, I'd like to propose a concept of push invoices. The idea is that it would utilize the message layer to provide invoices directly to nodes, rather than requiring a roundabout way for the user to present an invoice to their node. (e.g. scanning a QR code, clicking a URI, copy and pasting.)
The only aspect of push invoices that would need to be standardized would be some kind of message sent to the node that receives the invoice, likely via a BOLT #1 message with an invoice as the payload, and feature bits to indicate that you support receiving push invoices.
From there, the Lightning node implementation could do whatever they want with it. They could provide RPC interfaces to access the list of pushed invoices, notify the user via a push notification to some application they have, store it in a list of pushed invoices for when the user next accesses their node, or automatically pay the invoice based on some configuration from the user to auto-pay invoices. None of these would have to be implemented by the node, they're just possibilities.
Since invoices are encrypted via the recipient's private key, a push invoice could be delivered by a request from anyone, not necessarily the invoice creator. This would allow for nodes that aren't online all the time to still be able to send and receive push invoices by having an always-on centralized service do the delivery of them even if the sender or receiver is offline.
Motivation
I also recently started working on an allowance feature for Joule, but want to open up these kinds of payment possibilities to non-browser extension use cases.
Likewise, Casa recently released the Sats app that tries to make payments between people a bit easier. Unfortunately the way they've implemented it is specific to software that runs on top of LND with Casa nodes, so it's unlikely that a standard will form around their payment UX improvements.
Use Cases
1) Venmo-style Payment Requests
Alice would like to request that Bob pay her back for lunch. Alice sends a push invoice from her node to Bob's, who is then alerted by his Lightning mobile app that he has a new payment request. Bob confirms it on his app, and makes the payment. Alice is then notified that her pushed invoice has been paid.
2) Subscription Services
Alice would like to pay a monthly subscription to Bobflix for access to content. She configures with her node to automatically accept pushed invoices of up to 100,000 satoshis per month from the Bobflix node. Every month, Bobflix pushes an invoice to Alice's node. If that invoice fails to be paid, Alice will be contacted via her Bobflix account and be notifed that she failed to pay her subscription.
3) Streaming Micro-Payments
Alice would like to gain access to a video stream that Bob is running, but must pay to access it. She configures her node to automatically accepted pushed invoices of up to 1,000 satoshis per minute from Bob's node for the next hour. Every time her streaming client makes a request for a chunk of the video stream, Bob's node sends a push invoice to Alice's node. Should the push invoice not be paid, Alice's requests to get video data will be denied.
Would like to hear if people feel that this belongs at the node level, or if it should only be facilitated by layers on top of nodes.