From 7c417947817eaea3bdc548d9b625adb772c5597d Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 14 Sep 2021 10:26:08 -0300 Subject: [PATCH] lud-17 fallback scheme. --- 17.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/17.md b/17.md index 3f59472..76806c7 100644 --- a/17.md +++ b/17.md @@ -26,6 +26,16 @@ This document defines that LNURLs will have the format of conventional URLs, wit When `WALLET` sees a link or QR code like `lnurlw:domain.com/path` it should make a `GET` request to `https://domain.com/path`; and when it sees `lnurlp:examplennnnnnnn.onion/path` it should make a request to `http://examplennnnnnnn.onion/path`. +## Fallback scheme + +To replace the [_Fallback scheme_ from LUD-01](01.md#fallback-scheme), wallets should also allow for `https://`-prefixed URLs when scanning QR codes and handle them just like they handle `lnurl1...` links today. + +The idea is that the fallback scheme is expected to only be used in QR codes, never in links (the original intent of the fallback scheme was to be used in printed lnurl-withdraw vouchers, but this also applies to printed lnurl-pay QR codes like the [McDonald's ones](https://twitter.com/fiatjaf/status/1435251011527000066)). + +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. + ## Deployment Once most wallets signal their intent to implement, everybody can implement support for the new scheme, but keep supporting the old way for many years to come. Then new apps can start to use the new scheme.