Thread

This exact problem has been solved by email and PGP about 30 years ago. Basically you generate a master key from which you derive service keys that you can eventually announce (using the master key signature) that they should no longer be trusted at some point. This reduces exposure since only service keys are defacto used on NOSTR applications while the master key is ever so rarely used for retiring older service keys and announce a new one for that user.

nostr is the master key of frost, but frost is difficult 🤙

so you need a nip-85 provider to say if you can do social migration, if you can't do it you can say that your key is compromised so without tagging any pubkey and using a different kind. cc: nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

Yep, but for that scheme to even have a chance, we will need to migrate from our current keys.

You are correct and such a drastic change wouldn't be feasible either. What about if this is an optional feature? Those with existing keys can continue using them, this would be optional and available for users that have benefit/need of key rotation. Wouldn't impact existing users, wouldn't impact current way of nsec/npub. Would just state that npubABCDXYZ has authority to "expire" a key and define the successor.