Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] Push Invoices #644
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.
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.
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.
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.
A repo for that information sounds like a great idea. Definitely open to going that route instead. But the main benefit that I see for this being at the node layer is that you can leverage the peer to peer communication port that's already opened and discoverable on the network. Adding a layer on top would mean a new port with new mechanisms for finding other user's connection info for pushing invoices, and a new port that would require network configuration (ufw, router port forwarding etc.)
Small remark: When reading the description I was initially confused by the term "push invoice". To me, "push payment request" would be clearer. In the real world, an "invoice" is a request for payment, but in Lightning it seems that invoice sometimes refers only to the record in the recipient's database.