Nostr has two specs for key delegation/invalidation, namely, nip26 and nip41, so the future I want is easy to create: have a "hot key" that you use most of the time and a "master key" that you authenticate it with. If your hot key gets compromised, use your master key to invalidate it (either via nip26 or nip41 or both).
Clients who implement those standards will automatically migrate to your new key. Everyone else can rely on this time-tested alternative: notice that user-whoever has a new key (because they said so somewhere), manually unfollow/refollow them, complain they had to do this manually, someone in the comments will tell them "actually they use nip-blah so clients can automatically migrate to their new key if they just implement the spec," and then they can complain to their favorite dev to implement that spec so that their client automates this too.
No one can stop you from using key delegation/invalidation on nostr! It's just that those who choose not to use it will have a little manual work to do if your hot key gets compromised. But I think that's fine because that's already how it works (so it preserves the status quo for everyone who chooses not to use it) and it will just result in complaints to devs until they automate the migration process using one of the existing nips or perhaps a better one.
Here's an interesting and relevant comment from fiatjaf:
One nice thing about some of these proposals, like NIP-41, or the social-recovery method, or the external-source-of-truth-method, is that they don’t have to be implemented in any client, they can live in standalone single-purpose microapps that users open or visit only every now and then, and these can then automatically update their follow lists with the latest news from keys that have changed according to multiple methods. source
have a "hot key" that you use most of the time and a "master key" that you authenticate it with. If your hot key gets compromised, use your master key to invalidate it
Now this is sounding like what I'm hoping for!
"Dear Santa, I haven't been naughty this year, so..."
reply
Now this is sounding like what I'm hoping for!
My overall point is, you can do this right now. Nothing is stopping you. Create a master key, back it up, create a hot key, and sign a message with your master key saying "this is my hot key: <insert_hot_key_here>"
Now start using your hot key for everything, and if you ever lose it, sign a new message with your master key saying "this is my new hot key: <insert_new_hot_key_here> this hot key is no longer valid: <insert_old_hot_key_here>"
Nip 26 and nip41 formalize a way to do this but even if you can't find software that supports those nips, you can just do it manually for now and then nag devs to automate it for you via those nips or better ones
I recommend not waiting for "Santa" (devs) to do stuff for you. Start doing it and devs may follow.
reply
Two points well taken. (1) Do stuff yourself. (2) "My new hot key..." profile announcement on master.
This "profile announcement" technique has occurred to me and I may well do it one day.
The only downside is the bad actor still can pretend to be you in the "no longer valid" hot wallet. Bad stuff coming from my username and my avatar going out to my followers is a bad look. Gonna guess very few would ever do the legwork on corroborating things by checking my "master key" profile with its "this key is no longer valid" announcement. Frankly, who'd even know to look for such a thing?
The takeaway I'm gathering here is that it's simply not possible to "burn" a private key/nsec (to neuter its ability to do anything) and transpose the "account" (followers, notes, etc) to a new one. 😞
reply
The only downside is the bad actor still can pretend to be you in the "no longer valid" hot wallet
Sure but probably not for very long, word gets round
As soon as he does something bad people will stop following him and say "yeah I don't like so-and-so anymore because of X bad thing" and then someone else will tell them, "Oh, that's not him anymore, his key got compromised, this is his new key: <whatever> -- and btw if your client supported nip-whatever it would have automatically migrated you as a follower to his new key. Use client-whatever or ask your dev to add support"
reply