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
Login to reply
Replies (1)
* 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.