lud-17 fallback scheme.#94
Conversation
|
|
||
| If someone sees a QR code printed on a place, for example, they may know it's an LNURL thing and scan directly with their Lightning wallet, but they may also think it is a normal QR code or they don't even have a Lightning wallet, so they scan it and try to open it on their web browser. In that case the `SERVICE` may handle the request, check for the presence of `Accept: text/html` header and return a webpage with instructions. | ||
|
|
||
| This remains entirely optional and `SERVICE` should only use `https://` in printed QR codes if it is also willing to return a fallback HTML page. |
There was a problem hiding this comment.
Does this advice refer only to the case where the URL is encoded directly as a QR code and not when encoded using bech32 (e.g. "lnurl1...") then encoded as QR code?
|
@fiatjaf Maybe we can improve this fallback for QR Codes keeping LUD-1 fallback scheme like this https://someendpoint.com/lnurl/123456?lightning=LNURL1DP68GURN8GHJ7UM0D4JK2MNYWPHKJMN59E3K7MF0D3H82UNV9UCNYVE5X5MQEQFRPL < (that is this same previous link) This string encoded as QR code can work with old (only LUD-1 without change) and new (LUD-17) implementations without any problem |
|
I like this. @augustoresende's suggestions covers all cases. Services can choose to either do the |
|
bump |
andrerfneves
added
lud-extension
5 participants
No description provided.