Support of tags in LUD-16 static identifiers

[theborakompanioni]

The idea here is that, additionally to the <username>@<domainname> format of LUD-16 static internet identifiers, a SERVICE can offer multiple addresses resolving to the same user by using the format <username>+<tag>@<domainname>, e.g. satoshi+whitepaper@bitcoin.org (see Plus signs ("+") in email addresses). The normal flow does not change: Upon seeing such an address, WALLET makes a GET request to https://<domain>/.well-known/lnurlp/<username>+<tag> endpoint.

It is upon the SERVICE to decide what to do. If it supports tags, it SHOULD strip the +<tag> part and continue as normal.
A SERVICE MAY subsequently include the tag in the metadata property of the response:

[
        "text/tag", // optional
        string // the tag that has been passed in `<username>+<tag>`
],

Currently, the <username> character set is limited to a-z0-9-_. which means the + sign has not been allowed yet and wallets that are not aware of it will either just deny it, or support this change and immediately use <username>+<tag> as <username>. I suppose that most wallets do not validate for a-z0-9-_. and will happily use everything up to @ as username. The only tested wallet is Zeus, which supports sending usernames with +.

Example of a service that already accept +tag: https://ln.tips/.well-known/lnurlp/fiatjaf+test (albeit without resolving to "fiatjaf" and a dedicated entry in metadata)
Example of a service that does not support +tag: https://stacker.news/.well-known/lnurlp/fiatjaf+test

With all that said, I propose adding +<tag> as an OPTIONAL feature with a suggestion for SERVICEs to handle them accordingly. No already existing SERVICE is forced to update and can continue to work as is.

Benefits

With this suggestion, a SERVICE can offers users a "standardized" way to use multiple identifiers. e.g. a user can include fiatjaf+s01e01@ln.tips in the description of the first episode of a podcast, fiatjaf+s01e02@ln.tips for the second and so on and so forth. For written text it might be fiatjaf+article1@ln.tips, for code repositories it might be fiatjaf+poncho@github.com or fiatjaf+nos2x@github.com, etc.

Drawbacks

Since a user knows whether a SERVICE supports this scheme, an identifier with +<tag> is used only when this is the case - so there is no disadvantage on the SERVICE side. On the WALLET side, it might be that the GET request will not be performed if the wallet follows the current validation rules. In this case, a user SHOULD strip the tag manually - which is arguably not desirable.

---

Should this be an addition to LUD-16 or would you rather suggest this being a distinct LUD? Imho, an own LUD seemed overkill as the changes would be minimal and optional. What do you think?
Any and all suggestions are highly appreciated 🙏

[fiatjaf]

I see the point. I like this.

Do you have a concrete use case in mind?

Depending on the use case I think it would probably be better to use LUD-18 and attach other forms of payer data.
Receivers that support LUD-18 will already accept any kind of payer data -- although they won't know what to do with attributes they don't understand, of course.

[theborakompanioni]

I see the point. I like this.

Do you have a concrete use case in mind?

Concrete use case is a) proving multiple identifiers out-of-the-box, b) adapting the description dynamically. This is accomplished without the need to add any additional properties to the response.

Depending on the use case I think it would probably be better to use LUD-18 and attach other forms of payer data. Receivers that support LUD-18 will already accept any kind of payer data -- although they won't know what to do with attributes they don't understand, of course.

Ah, even better. I see now that adding "text/tag" is not worthwhile, as there is yet another field for wallets to optionally display. LUD-18 seems much appropriate. However, to support current use cases mentioned above, this is also not strictly necessary. If I understand correctly, SERVICEs can just as well adapt the text/identifier, text/plain or text/long-desc metadata entries to their own needs.

[dni]

i really like the idea!