There should be a key change NIP for Nostr.

Could be interesting too if you had it so that you had designated accounts to confirm a key change too. Like I would use my brother nostr:npub1ajv7m32k0cpgzha32qszsh304qusjvwwmavus0ttktzldms4xzusuftppj and maybe nostr:npub1rxysxnjkhrmqd3ey73dp9n5y5yvyzcs64acc9g0k2epcpwwyya4spvhnp8 or someone else I know really well in the space as “trusted verifiers.” Then if my key ever got stolen, even though both myself and the hacker could sign, I could make it so only I could transfer it to a new key by asking my verifiers to sign.

Maybe that’s too convoluted, but I feel like there should be a key cycling method regardless.

Reply to this note

Please Login to reply.

Discussion

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft (who else) had one that I’m not sure was ever merged but is in use. It involves creating an event defining a future key you might need to rotate to and then open timestamping that event to “notarize” the time.

I have some sort of odd mental block on remembering the number or the site on this one but I’m sure Pablo can fill in the blanks.

Convoluted?

no...

Confusing for tired brains like mine?

yes.

🥺🥺🥺

Absolutely!

"Social proof(optional): the event contains a list of people that the master keypair attaches to the revocation certificate as `p` tags. These pubkeys are designated as trusted identities that can judge/signal if the new proposed identity is trustworthy or not"

Working on it 🫡

We need this

nostr:note1rwnxgwc2xr7z2wv6zmfjnn9cds9zdu2qf0z7rkp3vfrsf5cz267s84k3lu

kind of like a multisig that has a master key. one dominates unless all 3 are used.

Yah social recovery for nip changes should totally be a thing.