Nostr Web Client

An interesting approach to gently transition from the current pattern to Nostr.

But it greatly reduces Nostr's “one key, multiple platforms” advantage during the first exploratory sessions, since the user cannot easily test other applications without running the exit procedure. Or worse, start creating multiple accounts to overcome this problem, and he cannot merge them later, of course. I think a lot depends on which application the user starts with.

Note: after ejecting the login procedure should remeber the old emails (hashing them), so:

A) It's able to point the user to the new login procedure that uses the ncryptsec;

B) Refuses a new registration with the same email, avoiding confusion for the user with more accounts;

Reply to this note

Please Login to reply.

Discussion

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.

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.

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

couldn't it just be a HTTP GET?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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.

> "Designed to be used with a single app rather than following the user around."

This undermines main the value proposition of nostr. Perhaps pressing into that vision is counter productive for nostr?

Definitely a trade off, but I think it depends: nostr:nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqy88wumn8ghj7mn0wvhxcmmv9uq3camnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhnyvtfv3jkzuewdehhxarjxyhxxmmd9uq3jamnwvaz7tmzwgh8qatjwpkx2un9d3shjtnrdakj7qpq8hhr9lmvgsf8ttd32hmxph2am7canlmjehy9fn809dahulvjuv0s6puhgl

brugeman 1y ago

Which flow have you settled on for now?

Good points. I think you're right that it strongly depends on the application. Only apps that could be considered platforms in their own right (e.g. flotilla, primal) should probably do this, since the exploratory dimension isn't part of that app's value prop (even if they are a bridge to the wider network). Maybe this could be solved by making the original app a bunker? "Log in with flotilla". But this would probably only increase the lock-in to the original bunker, which is the opposite of my goal.