LNUrl is not the only way for sending Lightning payments, and some other interesting methods which could be static files (Not connected to a Lightning node directly) could be useful for Lightning Addresses. The most interesting methods I think Lightning addresses could support are bolt12 and keysend payments.
This issue is mostly to gather feedback about what others think about this.
Implementations could work the following, backward-compatible way:
GET /.well-known/lightning-address/<user>: Returns data like the following: { supportedMethods: ["lnurlp", "keysend", "bolt12"] } where supportedMethods is an array of payment methods this address supports, sorted by the order in which they are preferred by the address owner. If this returns 404, assume the response is { supportedMethods: ["lnurlp"] }, so lnurlp will be used in step 2.
GET /.well-known/<method>/<user> Method is the method from before (Except for keysend, where it could be lightning-node to be less confusing regarding the content). Depending on the method, the data returned is different, lnurlp returns a standard LNURLp response, bolt12 could simply contain a bolt12 offer as a string, which already contains some metadata. It could be a json object too to have additional data.
Listing multiple methods is necessary in my opinion to allow clients to skip methods they haven't implemented yet (wallets connected to LND nodes can't use bolt12).
Benefits of this
Lightning addresses could easily be hosted on static sites
Lightning address servers would not require any node connection, which means the node does not need a public IP
Bolt12 offers and keysend node ids can be cached and re-used (Controlled like every other HTTP request using the Cache-Control header)
If a server supports lnurlp, it would still work with clients which don't understand this change
In my opinion, having this as part of the Lightning address protocol instead of LNUrl itself would make more sense, as Lightning addresses in most cases are for less complex use cases than lnurls support.
LNUrl is not the only way for sending Lightning payments, and some other interesting methods which could be static files (Not connected to a Lightning node directly) could be useful for Lightning Addresses. The most interesting methods I think Lightning addresses could support are bolt12 and keysend payments.
This issue is mostly to gather feedback about what others think about this.
Implementations could work the following, backward-compatible way:
GET /.well-known/lightning-address/<user>: Returns data like the following:{ supportedMethods: ["lnurlp", "keysend", "bolt12"] }where supportedMethods is an array of payment methods this address supports, sorted by the order in which they are preferred by the address owner. If this returns 404, assume the response is{ supportedMethods: ["lnurlp"] }, so lnurlp will be used in step 2.GET /.well-known/<method>/<user>Method is the method from before (Except for keysend, where it could belightning-nodeto be less confusing regarding the content). Depending on the method, the data returned is different,lnurlpreturns a standard LNURLp response,bolt12could simply contain a bolt12 offer as a string, which already contains some metadata. It could be a json object too to have additional data.Listing multiple methods is necessary in my opinion to allow clients to skip methods they haven't implemented yet (wallets connected to LND nodes can't use bolt12).
Benefits of this
Cache-Controlheader)In my opinion, having this as part of the Lightning address protocol instead of LNUrl itself would make more sense, as Lightning addresses in most cases are for less complex use cases than lnurls support.