I wouldn't treat an ncryptsec as secure as a lot of people will use weak passwords. Instead of sending it via email why not copy it to the clipboard or show a QR code? Also you could wait until the user has confirmed they successfully logged in elsewhere before deleting the nsec.
Thanks nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn for exploring new paradigms for nostr login and key management. I've been working on the login / signup / export experience for ngit and its really hard because because no simple solutions have emerged with acceptable trade-offs.
Discussion
I'm really uncomfortable with custodial key management solutions like this for nostr but I can see why its attractive.
An alternative approach could be to store the key on device and approve a new login from a new device running Flottila by sending the nsec eg via DMs with an ephemeral key. I suppose that's not much different UX than showing a QR code or copying to the clipboard like I suggested.
I wouldn't send via DM, but I do want seamless multi-device login for flotilla, which reliance on an existing session makes difficult
Burrow requires passwords to be at least 12 characters. Sending via email is a form of 2FA, since you need access to the password, and to the email account. That is at the expense of exposing the key to email servers, which you're right, isn't ideal.
couldn't it just be a HTTP GET?
oh never mind i was thinking the "set" side not the "recover" side or ? i'm not sure i understand
I do appricate the resonance with login flows the user might be familiar with but character length doesn't always equate to good entropy.
That's true. But I think it's a well enough understood problem that it is the user's responsibility at this point. Are there user-friendly ways of ensuring high-entropy passwords though? The "at least one number" policies are both obnoxious and ineffective.
The average person's understanding of password strength in the context of a system where the password can be changed later to protect the account. I'm not aware of any user friendly ways. Generate a random 4 word combo for the user that they will probably forget?
That's a good call, encrypting an nsec is a very different thing. Hmmmm
The main problem is that you ask for a password to create the account, I would avoid that and simply use a login via email using a temporary token with a very long session.
When the nsec must be exported, just create a password with some random words to have a good entropy, ask the user to repeat/write it down, and send the email with the ncryptsec.
But I need a password on signup anyway in order to authenticate with the server. Having two passwords seems unnecessarily confusing. Otherwise I like the idea.
Why do you need one password to authenticate with the server? A token sent via email with a 10 minutes expiration is fine. The signup can require only the email and validate the account at the first login (step that usually is necessary anyway).
I was thinking to authenticate further sessions, but you're right, you could do the email login every time, that's fairly familiar.
And the average user has just one device, max two, and don't has any tool to aggressively clear cookies (= sessions), so the need to redo the login should be quite rare.