Oddbean

▲ ▼

 Thanks for the write-up!

Questions:
- should username & email should be optional for create_account?  Clients shouldn't be forced to implement nip05 name selection, plus some bunkers might assign nip05 names from partners/different domains etc 
- create_account is only for signup? it could in theory work in exactly the same way for login - user enters their nip05 on the client, client sends create_account but the bunker just checks if such nip05 exists and does the auth
- Should bunker add itself to user's 31989 as handler for 24113? If it did, then if user changes their nip05 later, they could still login through a client with their new nip05 - client asks for nip05, checks .well-known of the new nip05 to see if it supports nip46 for this user, and if not - looks at 31989 to find the possible nip46 app for this user

▲ ▼

 * everything is optional (username, domain and email)
* yeah, `create_account` should be mainly for signup, if a user is trying to create an account with a name that already exists I think it would be better for the user to see that the username is taken. Then they might think "oh, I already signed up, I need to log in instead". I think this is a more familiar flow. The client can easily check if that username already exists (nip-05), so they could show a "are you trying to login? click here" or something like that

I think it should publish a 31989 but not for that reason. The NIP-05 is there just to find a pubkey, then the regular flow is what's really used, so the user changing their NIP-05 to something else is irrelevant, the `connect` request is sent to the user's pubkey, not to the bunker, so the 31989 is not really necessary to locate the bunker because the discovery of the bunker itself is not necessary.

▲ ▼

 > the `connect` request is sent to the user's pubkey

But to which relay? 31989 to find the domain which leads to .well-known with your nip46/relay. Or?

▲ ▼

 oh yeah, ideally the new NIP-05 would copy the `nip46` nip05 entry

▲ ▼

 Doesn't look nice, third-party nip05 can change it at will and user has no control over it, 31989 is at least at user's control and is signed.

▲ ▼

 Although the way I described it, new nip05 would be the priority :)
Anyways, since we're adding to 31989 anyways we could do both and figure out later which works better.