how to include the amount int lightning addresse

[renepickhardt]

Looking at the way how [email protected] is resolved via LNURL I don't get a standard way to have an invoice with which I want to send lets say 1337 sats.

can we have something like [email protected]/1337sat similarly how in scp we use the schema domain:/path where in our case the equivalent of the path would be the amount and I would not include another colon as that usually seperates the schema from the actual address.

I understand that using various techniques the sender could on a wallet level enter the amount but if I want to request a payment I would love to by the end create a QRcode that might encode a string like

lightningaddr://[email protected]/amount

which would be redable by wallets and wallets would know that they either request an invoice for the amount via the LNURL endpoint OR use one of the other techniques like keysend to deliver the amount.

for obvious reasons it would be nice to have a recommndation / best practice to ensure interoperability.

Of course a telegrambot could have a different api like send 1337 username which would internally get translated to the above standardized string

[LightningTipBot]

It's a hack but it's possible: You can send minSendable = maxSendable = 1337 in your LNURL endpoint which leaves you only with one valid amont ;)

[renepickhardt]

sure that is a quickfix but that still does not make clear how one should request such a payment for a fixed amount. I mean you could argue now that one could send an invoice directly for such an amount but I think one of the entire point of lnaddress is to have a standardized for custodial users to talk to each other.

[iangregsondev]

Is this still in alpha, meaning its possible to make changes at the moment ? Adding an option without the hack would be beneficial

Might be worth thinking about ways of introducing new features without a breaking change.

Some version in the metadata ?

Anyway, great product!!!

[bumi]

Does that still make sense to use an email-like format for such cases? or can it just be the LNURL directly?
domain.tld/.well-known/lnurlp/user?amount=1337 (works right now with any lightning address) - or just use a different LNURL (e.g. domain.tld/user?amount=1337)

[andrerfneves]

I'd agree with @bumi and say that the primary use for the human-readable internet identifier format is for the where do I request invoices from/send payments to piece. The amount and any additional metadata/properties shouldn't be part of the identifier itself. It just makes things more confusing in my opinion. It's also a slippery slope, why would we stop at amount? What if I want to add the comment to that as well, now we're doing [email protected]/amount=1337sat&comment=hellothere. I'm sure you can see how this can get very messy very quickly. Since LNURLPay are meant to be static endpoints, you can always create a button that uses {callbackURL}?amount=5000 which would return you an invoice for 5000 sats each time.

[hsjoberg]

It's a hack but it's possible: You can send minSendable = maxSendable = 1337 in your LNURL endpoint which leaves you only with one valid amont ;)

@LightningTipBot This isn't a hack, it's what you're supposed to do if you want to have a fixed amount.
Good wallets will handle this properly and just show the amount to pay.

[callebtc]

lightning:[email protected]?amount=10000&comment=Paywall%20access would be akin to the already common mailto:[email protected]?subject=Mail. I think these should be provided only as clickable links / URI's anyway, so the messiness André is referring to isn't an issue in my view.

[bumi]

@callebtc if it should be clickable (thus it's mainly for the computer) why not a normal LNURL link?
I don't think that's what human readable internet identifiers/lightning addresses are for.

[hsjoberg]

Lightning Address is dependent on LNURL-pay. These things are already solved within that payment protocol.

Adding query parameters to a Lightning Address just brings more issues than it solves.
What would a wallet do if the data provided in the LNURL-pay response aren't the same as the data in the query params?

So I concur with @andrerfneves, the place to provide these kinds of things is within LNURL-pay itself.
It's also an extensible protocol, if you have any other suggestions for improvements or features.
As an example, LUD-18 was recently specified which amends the protocol with the ability to provide a payer identity to the payee.
In other words, it's possible to know from which Lightning Address the payment came from.

[trbouma]

I am not sure I understand the technical downsides, but it would be great to specify a lightning address with an amount like this.

[email protected]?amount=milliSatoshi

Eliminating keystrokes is paramount.The use case I am thinking of is putting a donation QR code for donations on a cross-country ski trail, where users with very cold stiff fingers will likely only be able to unlock the phone, open the app, scan and confirm. No typing.

As well, it would be really easy for a non-technical user to generate a corresponding QR code for varying amounts like this

(note: if you try to scan this with a wallet, you'll get an error. It is just encoding [email protected]?amount=1000 )

I totally understand that there may be technical issues, but I see this simplicity to specify amounts as a usability winner for Lightning Addresses. This may require a modification on the Lightning Wallet vendors on accepting this format, but I think it would be a big winner.

[bumi]

@trbouma just use the full URL in the QR code: https://lnpay.ca/.well-known/lnurlp/payme or in your case (because you run LnMe) also: https://lnpay.ca/lnurlp/payme

[hsjoberg]

@trbouma

Eliminating keystrokes is paramount.The use case I am thinking of is putting a donation QR code for donations on a
cross-country ski trail, where users with very cold stiff fingers will likely only be able to unlock the phone, open the app, scan and confirm. No typing.

This use-case is already covered within LNURL-pay protocol.
Lightning Address is not a payment protocol, it's directly dependent on the underlying LNURL-pay protocol where paying fixed amount of sats is widely supported and adopted across the ecosystem.

Really if you want to print out a QR-code, there's no need to use Lightning Address whatsoever, you can use LNURL-pay from the different server applications and services available today. 

Perhaps I'm missing something here, but I firmly believe we got everything covered -- Lightning Address might be new, but LNURL-pay has existed and worked for people for years already.

(note: if you try to scan this with a wallet, you'll get an error. It is just encoding [email protected]?amount=1000 )

Yes, it will break virtually all implementations of Lightning Address.

I totally understand that there may be technical issues, but I see this simplicity to specify amounts as a usability winner for Lightning Addresses

This technical issues should not be taken lightly, it requires all implementations today to update their wallet code.

This may require a modification on the Lightning Wallet vendors on accepting this format, but I think it would be a big winner.

I disagree, I believe we can already do all the things you want with LNURL-pay, especially in the scenario where QR-code is the medium.

@trbouma just use the full URL in the QR code: https://lnpay.ca/.well-known/lnurlp/payme or in your case (because you run LnMe) also: https://lnpay.ca/lnurlp/payme

Yes, this will work, but mind you that it has to be bech32 encoded first by this simple tool: https://lnurl.fiatjaf.com/codec.

At least until LUD-17 is widely adopted.