Secure storage and transfer are the goal indeed.
Encrypting the nsec locally should be default and NIP-49 has great promise. Especially if it's easy to check whether a FOSS app implemented it and does ONLY that with your nsec. Very cool things you can do then.
Issues I ran into though:
1. How do you transfer the encrypted nsec to another device? Once it's out there, it's out there and your single password will be hacked in no time.
I thought of automatically sending their encrypted nsec to their phone number or email on sign-up with a sign-up link for other devices etc... But nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr quickly made me realize how dumb that was.
2. How do I onboard users to actual keys (nsec + npub), give them agency, make it fun and have it work for every language?
3. How do they secure their key beyond their device? 12 random English seed words on paper, really!?
4. NIP-05 + password is the worst of both Big Tech and Nostr. (it took me a while and actual tests to see why)
Normies do NOT understand it. It's not an email but looks like it. Why can't they use their own email? Sometimes it's hosted locally, sometimes it's in the cloud. It has a delay. It relies on domains being available. Etc...
Maybe I'm too much on the extreme ends here, but since we have no proper cryptographic mechanism for keypairs, if an nsec is ever stolen, you permanently lose your identity and every account that used it for authentication. Because of this, I don't think we should be building any tools that can pose risk to key theft SOLEY for the sake of convenience or on-boarding.
Great the UX is easy, and tons of people sign up, go transferring their keys all over the place and many of them will get their identities stolen.
Yes I understand the argument: well it's probably better than users copy-pasting nsecs everywhere, yeah it probably could be. Still think that's a different argument though. Nostr is different than traditional app UX, I think we need to stop pretending we can make it work how people are "used to it" and educate.
I'm not sure where we need to take these actions, but I will still advocate for less key attack surface area. My signing app doesn't even have the code to extract private keys and likely never will.
Something also worth mentioning on the encryption side is: you can't put the toothpaste back in the tube. Once someone, or governments go hoovering up encrypted anything, if the encryption is ever found to be weak, your keys have now been compromised. We saw it happen with early SSL and the NSA, and is likely still happening. But that was just passive attacking, this allows for unrecoverable active attacks.
To my knowledge no other system functions with this much risk. I can't think of another scenario where a user doesn't have the ability to counteract and active attack.
Certificate authorities can issue revocations to limit damage
Bitcoiners can move funds if they get nervous or have many wallets
SSH can issue new certs
PGP can regen or issue revocations
Passwords can be changed
Bank accounts can be closed and reopened
TLS connections are generally short lived
nostr keys have no countermeasure whatsoever.
Yes. Nostr is going nowhere without key rotation.
Thread collapsed
This is also exactly why sending around encrypted nsecs over internet is not something to normalize.
buuuuut … Encrypting nsec for private (everyday) use should still be best practice.
So … right now, I see the best “normie” onboarding experience is to simply encrypt and store (not share) their new nsec “in the cloud”. Let their “web of trust” do the key education. Here’s how:
- incentivize “nostr advocates” to invite their friends.
- ask for U&P (only) upon invite.
- create Nip05 with username.
- encrypt nsec with password.
- allow for logging in ( anytime to the onboarding client) with U&P and pasting OUT encrypted nsec for use in other clients.
- encourage advocates themselves to educate their new friends about key management, recomended clients, quality content and follows, and other Nostr pro tips all from WITHIN the onboarding app.
Tell me there’s a better way for onboarding today…
If we are strictly talking on-boarding, can't argue with that. A simple and secure solution first/default. If they want to leave/branch to other clients they can learn how to extract their keys, or try more secure management solutions.
Once client apps get better I can't imagine there will be as much client swapping as we do today. So it doesn't have to be easy to swap clients. I wouldn't swap so often if each client didn't have major UI issues that cause me to switch between them.
I also have to imagine some (or most) mobile clients will simply setup a nip46 signer in-app in the future anyway so if users want to try other clients they just need their starter app which is currently holding their keys, no nsec extraction necessary.
To your point … I’d like my onboarding client to double as a signer … but without key custody…. In the future.
This is how I see onboarding best practice…. Now all we need is funding to move fwd… 🤷🏻♂️
>Now all we need is funding to move fwd
Same brother!
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
I'm not advocating for transferring keys everywhere and I'm working on a solution that avoids and disincentivizes it when not warranted (95% of cases). Again, above is what I'd do for nsec creation, memory and ease of transfer. Not because I'll make them enter it everywhere.
Putting the keys front and center matters.
Doing that is not at all what people are used to.
The more fun and agency I can built in, the better.
And the smaller the attack surface will be in the end.
Give normies an nsec and see what they do with it. Fun assured 😂 .
Thread collapsed
Thread collapsed
