Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: On Tue, Sep 21, 2021 at ...

📅 Original date posted:2021-09-21
📝 Original message:
On Tue, Sep 21, 2021 at 3:06 PM fiatjaf <fiatjaf at gmail.com> wrote:

> I would say, however, that these are two separate proposals:
>
> 1. implementations should expose a "stateless invoice" API for receiving
> using the payment_secret;
> 2. when sending, implementations should attach a TLV record with encoded
> order details.
>
> Of these, 1 is very simple to do and do not require anyone to cooperate,
> it just works.
>
> 2 requires full network compatibility, so it's harder. But 2 is also very
> much needed otherwise the payee has to keep track of all the invoice ids
> related to the orders they refer to, right?
>

Not completely sure what you mean by full network compatibility, but a
network-wide upgrade including all routing nodes isn't needed. I think to
do it cleanly we need a new tag for bolt11 and node implementations that
carry over the contents of this field to a tlv record. So senders do need
to support this.


> But I think just having 1 already improves the situation a lot, and there
> are application-specific workarounds that can be applied for 2 (having a
> fixed, hardcoded set of possible orders, encoding the order very minimally
> in the payment secret or route hint, storing order details on redis for
> only 3 minutes and using lnurlpay to reduce the delay between invoice
> issuance and user confirmation to zero, and so on).
>

A stateless invoice API would be a great thing to have. I've prototyped
this in lnd and if you implement it so that a regular invoice is inserted
'just in time', it isn't too involved as you say.

Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/e683619e/attachment.html>;