Skip to content
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

[RFC] Push Invoices #644

Open
wbobeirne opened this issue Jul 17, 2019 · 4 comments

Comments

@wbobeirne
Copy link

commented Jul 17, 2019

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.

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Jul 17, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 17, 2019

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.)

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Jul 17, 2019

That's true, I'm curious to see what other implementers think.

@joostjager

This comment has been minimized.

Copy link

commented Aug 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.