author: akumaigorodski author: andreneves author: fiatjaf discussion: https://t.me/lnurl/11610

The idea here is that a SERVICE can offer human-readable addresses for users or specific internal endpoints that use the format <username>@<domainname>, e.g. satoshi@bitcoin.org. A user can then type these on a WALLET. The <username> is limited to a-z0-9-_. (and + if the SERVICE supports tags). Please note that this is way more strict than common email addresses as it allows fewer symbols and only lowercase characters.

Upon seeing such an address, WALLET makes a GET request to https://<domain>/.well-known/lnurlp/<username> endpoint if domain is clearnet or http://<domain>/.well-known/lnurlp/<username> if domain is onion. For example, if the address is satoshi@bitcoin.org, the request is to be made to https://bitcoin.org/.well-known/lnurlp/satoshi.

The response from SERVICE then MUST be the same as in LUD-06, step 3, and the flow is the same.

If providing such a scheme, SERVICE MUST add to the metadata JSON array either a text/email entry or a text/identifier entry, as in examples below:

[
    "text/identifier", // indication that this payment link is associated with an internet identifier string
    content // an internet identifier string in standard user@site.com format
]

or

[
    "text/email", // indication that this payment link is associated with an email address
    content // an email string in standard user@site.com format
]

The text/email entry MUST be used if the internet identifier corresponds to an actual email address.

A SERVICE can offer multiple identifiers resolving to the same user by using the format <username>+<tag>@<domainname>.

Upon seeing such an address, WALLET makes a GET request to https://<domain>/.well-known/lnurlp/<username>+<tag> endpoint.

A SERVICE SHOULD strip the +<tag> part and continue as normal and MAY add a text/tag entry to the metadata JSON array:

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