Also, I’m not sure how many so-called “content creators” or influencers actually want to build a following on #Nostr, knowing that if they lose their private key or if it gets compromised, they’re just shit out of luck.
There’s nothing they can do. Of course that turns people away.
nostr:nevent1qvzqqqqqqypzp8yls8khjhc0tma9tzfjsfrg0kz0cln2fnaxmdwk6w6sljmlltkzqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7mn0wd68ytn00p68ytnyv4mqz9nhwden5te0wfjkccte9ehx7um5wghxyctwvsq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqqgxru49wmgsgwzusrch8gk7ekee3mnp3sxllcjquswept9ljyx4h6yrkt5sn
Replies (11)
Keys are a huge problem.
One solution is a NIP for designating a backup NPUB, as soon as you create your original one. This designation must be immutable.
Then, if NPUB 1 is breached, user presses the big red button to engage NPUB2. Forming the equivalent of a 301 redirect on Nostr.
Since the NPUB 2 designation was made before the hijack, it doesn't matter if a hijacker has access to NPUB 1. The original user can still press big red button, migrating to NPUB 2 which hijacker can't control.
Interesting idea. So you get a second chance if you lose your private key.
That would only solve a compromised NSEC, not a lost/forgotten one.
Would have to think on lost key solutions.
IMO we need seed phrases or a seed phrase to nsec converter. Because seeds are much easier to remember than nsec. But that's not a full solution.
If you already declared a backup npub (npub2) when creating the Nostr account (npub1), then you could activate it without even having the nsec for npub1 - or do you need the old nsec as well?
Having seed phrases would certainly be nice.
You'd need to be logged in, otherwise anyone could initiate it and scuttle a perfectly good nsec.
The cleverness is if both a hijacker and the true owner have access to npub1, the hijacker would never activate the failsafe, since that would cause him to lose the acct.
It's basically a perfect solution.
Ah, I understand.
I hope clients will implement the solution at some point.
How do you know what happened before what?
The timestamp in Nostr events is not certified by default. It's only signed as part of the event, you can post from the past and from the future if you want.
Would that require certifying timestamps, thus adding more complexity? Consider this is aimed at the dumbest users, the most likely to paste their nsec where they shouldn't.
I'm not sure time matters.
An immutable nsec and NPUB can be created, I don't see why an immutable failsafe NPUB can't also be created.
Maybe I'm misunderstand exactly what you mean?
You would need an event signed with the first key that references the backup key, no?
If I get access to your private key, I can just publish an older event certifying a public key I control.
Anyone who tries to visit your account will be redirected to the oldest verified public key (my own).
I think it might need its own NIP.
Ok, but how would you actually technically achieve what you want?
