mikedilger
Wizard - Login flow
In the first view the user can choose the different login possibilities (here are present also the future NIP-46):
Plain private key option (nsec, hex), the user is immediately offered the option of encrypting the key:
But can opt-out and go on without any encryption:
Encrypted key option (ncryptsec1), the user need to input the passphrase:
The user is offered the option to automatically search for data associated with his or her account:
Or to specify a relay:
If nothing is found a message explain the matter and the user can skip the procedure, or switch option:
if something has been found, it is shown. If we have the name of the user, it is used in the title:
The user can see the relays and manage them. If no data have been found, we propose a random set like in the creation flow (here the text should be updated and adapted):
Final step we confirm that the account is ready. If the user has encrypted a simple private key, the user is reminded to download the account and keep the passphrase safe:
I moved the "Login with a public key" on the first step of the wizard (I will open a issue about this specific step)
A couple of things.
First, our code doesn't let us store private keys without encrypting them. We can fake this experience by encrypting the key under a blank password, but we will have to add code to either test the blank password or indicate it somehow. I think we already discussed this. So no changes needed for this, I just thought I'd point it out.
Also, encrypting your key later is like closing the barn door after the horses are gone. People might do it, but we shouldn't suggest it being a viable alternative.
Second, there is a difference between the user choosing to discover their setup at wss://purplepag.es versus to find their stuff at wss://chorus.mikedilger.com:444. I think we currently let them choose which discovery relay to look for their relays at, but this flow collapses these steps. The steps are: 1) discover your relay list, 2) find your stuff at those relays. In the best case, this can flow immediately through and appear as a single step, but in the worst case the user will have to enter a discovery relay, and then later enter a relay where there stuff is. I only see a way to enter a single relay for both of these tasks.
@mikedilger
Also, encrypting your key later is like closing the barn door after the horses are gone. People might do it, but we shouldn't suggest it being a viable alternative
Fair point :) We can discourage the password-less path replacing the radio options with an opt-out link below the main button. Something like that:
The only alternative I can think of is to allow, like now, an empty password. In this case we should ask a confirmation ("You are really sure that you want use an empty password"). But this would create a really weak ncryptsec (actually fake) and it could lead the user to make mistakes.
I think we currently let them choose which discovery relay to look for their relays at, but this flow collapses these steps.
Currently we ask for a relay where find a kind-03:
In my proposal the user can enter a "discovery relay" (supposed to be NIP-65, but not necessarily, we can offer a suggestion on this), and we can find all the relays; if this fails the user can always redo the discovery with a new relay, or review the relays in the next step. I would also allow the user to add a profile n or a NIP-05 address as an option to the discovery relay, so that there are probably more relays to search in one step.
I would definitely remote the "(kind: 03)" thing. Is that really in there? Your profile is a kind 10002, a kind 0, and a kind 3.
I understand that an ncryptsec with an empty password might lead users to think it is safe because it is encrypted. BUT we have a real programming challenge to do it any other way. I intentionally avoided any capability to store a naked secret to make sure we don't accidently leak that secret. If I go add back a way to store a naked secret, then a bug could arise where we leak it accidently.