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 known since a long time ago that iPhones are not very smart in the way they handle protocol schemes, so it is better for many reasons to have LNURL-related things separated from the lightning:
URL scheme.
As that is a breaking change it's better to go even further and break different subprotocols each into its own scheme prefix, since an app can implement one and not the other and that's very normal, so this document defines the schemes:
lnurlc:
for LNURL-channel, i.e.channelRequest
;lnurlw:
for LNURL-withdraw, i.e.withdrawRequest
;lnurlp:
for LNURL-pay, i.e.payRequest
;lnurla:
for LNURL-auth, i.e.login
;
The idea of bech32-encoding stuff was based on a flawed assumption that this would make QR codes less complex. Besides having the opposite effect, bech32-encoded URLs have also the disadvantage of hiding 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 big, which has its merits but it's not that big of a deal. The only reason we keep using bech32 is that to change it would break everything. Since this document already contains breaking changes, let's just use this opportunity to also get rid of bech32 once and for all.
This document defines that LNURLs will have the format of normal URLs, with the prefixes lnurlc:
, lnurlw:
, lnurla:
and lnurlp:
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.