Skip to content
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

Default username? #28

Open
Falci opened this issue Nov 27, 2021 · 6 comments
Open

Default username? #28

Falci opened this issue Nov 27, 2021 · 6 comments

Comments

@Falci
Copy link

Falci commented Nov 27, 2021

This "username @ domain" is great for 3rd-party services like zbd.gg or bitrefill, but they seems unnecessary for personal domains.

You end up with [email protected], [email protected] or [email protected].

Could we just use @mydomain.com in this case?

What do you think?

@andrerfneves
Copy link
Owner

What's wrong with [email protected] for example? The Lightning Address follows the Addr-Spec Specification RFC which is an internet standard and it requires a username portion followed by a domain portion with the @ sign in between.

https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1

@Falci
Copy link
Author

Falci commented Dec 6, 2021

Nothing wrong.

they seems unnecessary for personal domains.

it's not pay at falci.com it would be pay to falci.com

@lukechilds
Copy link

I have the same request.

What's wrong with [email protected] for example?

@andrerfneves One issue is that it's not a common identifier between platforms. e.g if I have [email protected] for Lightning Address and [email protected] for Nostr and then [email protected] for another services it makes discovery between services a bit clunky. I could of course use [email protected] for everything but it just seems kind of unnecessary.

One suggestion taking inspiration from NIP05 would be to have "_" reserved as a special default username.

so:

username@domain   >   https://<domain>/.well-known/<username>
@domain           >   https://<domain>/.well-known/_

Thoughts?

@lukechilds
Copy link

@andrerfneves any further thoughts on this?

@andrerfneves
Copy link
Owner

andrerfneves commented Feb 5, 2023

I've spoken to a lot of people about this and the unanimous feedback is that since this is something that wallets would need to implement themselves in order to work, and is a fully optional item, then it should be fine. I quite like what this can enable. I was hesitant at first because it adds additional overhead on the simplicity of the protocol, but seeing the ease of NIP05 aliases with support for both of these methods, I am convinced of its benefits.

cc @Falci

@andrerfneves
Copy link
Owner

@lukechilds what's next here

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

No branches or pull requests

3 participants