Adding onto this, the only thing saving them is that they can change their password. Now you want them to have something like a password, but much longer and impossible to remember and oh yeah, if you lose it or it gets stolen there’s no way on heaven or on earth to change it?
Nope.
We don't have any other option right now. They have to store a private key.
I agree with a lot of what Shawn is saying. I like nosta but I think we could also have a less thorough version of that. And Shawn, you bring up many good points although with a bit of defeatist attitude. I do agree that we have many challenges here, but also think we can bridge them somewhat, even if imperfectly.
For one, I don’t know if we really need to explain nostr at all. This could be a progressive discovery function and a thing you learn along the way. Clients could build their own brands. This could alleviate some confusion. Users can slowly ease into concepts along the way.
I don’t agree that people don’t know what passwords are - I think everyone does by now. People also use password managers, key chains and now passkey. Yeah, we’ll get a bunch of people who lose access but maybe we can work out something down the road. In the meantime we can make used of what’s available.
It’s good to hear sobering feedback but let’s not interpret it as the end of the road. With other issues in the table, password are the least of our worries.
I’ll design what I think would be a good “low effort” version of nosta and we can always test both.
For web clients I don’t see a need for this. It’s one splash screen to greet a person and off into their own onboarding flow.
I’ll conclude by agreeing with Vitor that there are concepts people have to learn when coming here that cannot be abstracted away any further. We can ease the learning but learn they must.
If this sounds too difficult, sit back and let me worry about it :)
I do like Nosta, but I can't see it as an onboarding client. It's too much graphics. We need simpler things.
But we can always have competing onboarding clients :)
I agree. I thin the ideal in-between client would be unbranded / more generic. It’s a good option to have but for different needs.
I’m sorry, I didn’t mean to sound defeatist. I think this is a huge opportunity to improve UX.
I’m encouraged by the work nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft has done with nsecBunker and whatever he was hinting at today:
nostr:note1qmuakk7f6zr3h8x0ng7ryc8rw2f2vjdr2ka74ayvh4lxr4hrk3jswxuqcp
And to be clear, I love the architecture of public/private key authentication. It just needs a little abstraction to make it less threatening. For example, here’s how Apple handles it:
https://support.apple.com/en-us/102195
Apple of course has the ability for deeper integration into the device than normal apps, but maybe we can learn from this.
Look, if someone were to implement Nostr across their entire company, it would need to integrate somehow into their existing IdP. (Active Directory, Okta, SAML, OAuth, whatever.)
They would need an interface to create (or maybe import, or not) their npub and nsec. And maybe change it somehow without losing history. Generic departmental accounts would need to exist where the person using it can’t access the nsec.
And then it needs to be stored and accessed easily when people need to use it. But be able to have their access to the departmental account revoked when they leave the company or even change jobs within the company.
Maybe nsecBunker can help there, but I admittedly haven’t dug into it enough to see where it meets this.
