You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like LUD-16 isn't complete without also being able to specify static invoice/invoiceless information in the LUD-6 object. It could be added easily, like so:
This would allow for generating invoices, as normal, but also gives the staticPayment info in case the receiver also allows for static invoicing (keysend/amp/bolt12). The method would dictate the type of static info the object is describing. This is modeled off of the Value4Value spec in the podcast namespace:
There are other proposals in the Lnurl telegram group that are being discussed, so this may not be needed. I'll leave it here for now and close later once decisions are made.
This is the first that I am seeing of anybody working with LNurl in the same ways that ive been trying for the past 2 months!!!! Nobody ever really knows what im talking about when I bring up topics like these because I always run into the same static problem here, where else can I get in contact to talk about these concepts or read more about these?!?!?!? Im not the MOST versed with reading these back end views.
I had to make an entire account for this site when I found this project has been open for longer than ive been working on it, exciting because it means were definitely on the right path because we're all approaching it from different angles and we're around the same area.
It seems like LUD-16 isn't complete without also being able to specify static invoice/invoiceless information in the LUD-6 object. It could be added easily, like so:
This would allow for generating invoices, as normal, but also gives the
staticPayment
info in case the receiver also allows for static invoicing (keysend/amp/bolt12). Themethod
would dictate the type of static info the object is describing. This is modeled off of the Value4Value spec in the podcast namespace:https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md#lightning
...which has worked extremely well. Being able to use Lightning Addresses in the v4v payment blocks would need something like I'm describing here.
The text was updated successfully, but these errors were encountered: