author: fiatjaf author: fitti discussion: https://github.com/fiatjaf/lnurl-rfc/pull/66#issuecomment-868407854 draft
This is a breaking change. It requires all implementing wallets to agree to be considered "final".
It's been known for a long time that iOS devices are not very smart in handling URL schemes. For this, and other reasons, it is better to have LNURL-related protocols separated from the lightning: URL scheme.
As that is a breaking change, it's better to go even further and assign each subprotocol its own URL scheme prefix, since an app can reasonably choose to implement only a subset of these. This document defines the prefixes:
lnurlc://for LNURL-channel, i.e.channelRequest;lnurlw://for LNURL-withdraw, i.e.withdrawRequest;lnurlp://for LNURL-pay, i.e.payRequest;keyauth://for LNURL-auth, i.e.login;
The idea of bech32-encoding was based on a flawed assumption that this would make QR codes less complex. Besides having the opposite effect, bech32-encoded URLs also have the disadvantage of obfuscating the domain names, being arcane and weird, and forcing both wallets and services to rely on bech32 libraries everywhere. The only points in favor of using bech32 are: (i) it provides a nice "lnurl1" prefix, but this is pointless as the protocol schemes above will address this; (ii) they yield a single string that is easy to copy-paste, even if long, which has its merits but is not particularly important. The only reason we keep using bech32 is that its removal is a breaking change. Since this document already contains such breaking changes, we shall use this opportunity to also get rid of bech32 once and for all.
This document defines that LNURLs will have the format of conventional URLs, with the prefixes lnurlc://, lnurlw://, lnurlp:// and keyauth:// replacing https:// (for clearnet URLs) and http:// (for onion URLs). For example:
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.
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.