breez-sdk
breez-sdk copied to clipboard
breez
Feature request: get info about pending incoming payments
As a user, I would like to be able to see previously requested payments, even if they haven't been received yet.
When an invoice is created using receive_payment(), the method list_payments() could start returning a pending payment associated with that invoice.
Filtering options could be added to avoid returning these pending inbound payments to consumers of the SDK that aren't interested in them.
We use the term pending to indicate in-flight payments e.g. those that have pending htlcs so I think we should find different semantic here.
We think of the list_payments as a list which wallets (for example) would show to the user as part of a payments list.
Are you looking to show these unpaid invoices as part of the payments list as well? Or is this a different use case?
We use the term pending to indicate in-flight payments e.g. those that have pending htlcs so I think we should find different semantic here.
Sure, a different term could used.
We use the term pending to indicate in-flight payments e.g. those that have pending htlcs so I think we should find different semantic here. We think of the list_payments as a list which wallets (for example) would show to the user as part of a payments list. Are you looking to show these unpaid invoices as part of the payments list as well? Or is this a different use case?
Yes, the idea would be to show it in the payment list.
@danielgranhao displaying unpaid invoices in the payment list doesn't really sense. Not sure I'm aware of a single wallet that display unpaid invoices. Perhaps we can have an separate API that fetches the invoices with their status. But I'm not sure it fits into "payments" semantics.
@kingonly I think it can make sense since an invoice can be relatively long-lived, and the user can keep track of it to remember that he asked someone for money and is still waiting to receive it. But it's true not all users will be interested in this information; that's why I suggested allowing these "pending" payments to be filtered out.
Regarding using a separate API, that would be cool as well. We can just combine the results ourselves.
In principle makes sense, but AFAIK long-lived invoices are not really practical, because the issuer has to be online to receive.
There are efforts underway to allow for offline receiving, but that's not ready yet.
Is there a use-case you had in mind for the long-lived invoices?
So we will go with different API for unpaid invoices same as requested here: https://github.com/breez/breez-sdk/issues/400
@ok300
In principle makes sense, but AFAIK long-lived invoices are not really practical, because the issuer has to be online to receive. There are efforts underway to allow for offline receiving, but that's not ready yet.
I'm aware and agree that it will make more sense when it's ready
Is there a use-case you had in mind for the long-lived invoices?
It will be more useful when we have offline receiving, but even now, I think it slightly improves UX. If a user creates an invoice and sends it to someone who owes him money, but that person doesn't pay immediately, even if they have to later coordinate to make the payment, it can be useful for the user to be able to check the unpaid invoice in the app in the meantime.
It will be more useful when we have offline receiving, but even now, I think it slightly improves UX. If a user creates an invoice and sends it to someone who owes him money, but that person doesn't pay immediately, even if they have to later coordinate to make the payment, it can be useful for the user to be able to check the unpaid invoice in the app in the meantime.
Hmm... I don't think so. There could be a very high ratio between unpaid and paid. There's more cons than pros. Also mid/long term with bolt12, it really doesn't make sense because the users will long longer request payments.
Hmm... I don't think so. There could be a very high ratio between unpaid and paid. There's more cons than pros. Also mid/long term with bolt12, it really doesn't make sense because the users will long longer request payments.
I think it really depends on the user's behavior and preferences. I don't see what are the cons if the list can be filtered. Even with bolt12, won't there always be a place for requesting payments?
If it's 90% requests, it matters. It's just not a payment and there's a reason non of the existing wallets are showing it. It's so much information, it doesn't mean a lot to users. Anyway, we're implementing a separate API so we're ok.
@dangeross FYI some operations, like reverse swap, already kept track of certain pending LN payments, but purged them if they timed out (relavant commit). Hopefully this comes in handy for the bigger pending payments topic.