10000 feat(LUD-16): support for multiple identifiers by theborakompanioni · Pull Request #277 · lnurl/luds · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat(LUD-16): support for multiple identifiers #277

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 12, 2025

Conversation

theborakompanioni
Copy link
Contributor

Resolves #197.

Adds support for +<tag> when paying to static internet identifiers.

Copy link
Collaborator
@dni dni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice addition

@jklein24
Copy link

+1 - we actually added + to the UMA address spec for this exact use case :-)

@dni dni requested review from andrerfneves and hsjoberg June 10, 2025 09:29
Copy link
Collaborator
@hsjoberg hsjoberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

< 8000 /form>

I like this.
Although this is a breaking change as current LUD-16 implementers would not accept Lightning Addresses with a tag.

@theborakompanioni
Copy link
Contributor Author
theborakompanioni commented Jun 10, 2025

I like this. Although this is a breaking change as current LUD-16 implementers would not accept Lightning Addresses with a tag.

You are perfectly right, however, as described in #197:

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.

So in practice this should not lead to any problems on the SERVICE side (as users would just not use the feature).

It is a different story on the WALLET side, if it strictly implements previous validation:

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.

In practice, some wallets do not validate the address and just perform the GET request as is, e.g. tested with wallet is Zeus, which supported sending usernames with + (at the time of writing).

What do you think?

@dni
Copy link
Collaborator
dni commented Jun 10, 2025

I like this. Although this is a breaking change as current LUD-16 implementers would not accept Lightning Addresses with a tag.

i think current implementation would just see it as new address and would probably just throw a 404 or similar, but that is on the user to not use the tag on an unsupporting service. its also simple for the user to test if a service supports it, just try fetching an invoice with that address + tag.

@andrerfneves
Copy link
Collaborator

Ack. This is good 👍

@hsjoberg
Copy link
Collaborator

It is a different story on the WALLET side

@theborakompanioni Yes, I was mostly concerned about WALLETs implementing it strictly.

Anyway I don't think this is a big deal.

I'm for merging this one.

@dracos4lyfe
Copy link

How do I start creating my own codes

@theborakompanioni
Copy link
Contributor Author

How do I start creating my own codes

The idea is that you should be able to append whatever you like to your existing lightning address. They do not really exist and are "created on the fly" when people use them.

@dni dni merged commit 227f850 into lnurl:luds Jun 12, 2025
@andrerfneves
Copy link
Collaborator

Implementing this in ZBD side asap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support of tags in LUD-16 static identifiers
6 participants
0