A simplified version of the idea requires not choosing the 5 people beforehand, but instead relying on people that you followed before the key was compromised.
Unfortunately this doesn't work immediately because the attacker can publish backdated events changing your follow list. But I think some gimmicks can be made so this will work too, with a little bit of ambiguity and trust in relays, maybe.
I was thinking the other day that just a revoke event that suggests a new key could work.
Clients would then prompt and give notice that the key has been revoked and suggest moving to the new key while providing additional information.
A client could use their own follow graph for additional verification.
For example, Bob and Carol know each other well, Alice follows both of them. Bob revokes his key and suggests a new one. Alice's client notices Carol now follows Bob's new key and displays it in the prompt to switch. Alice then follows Bob's new key.
Backdating events is also the problem of predesignated successor accounts (what I called canaries).
Did you ever think about how timestamping could work in nostr?
I imagine doing this right is not so easy (after all this is what Bitcoin solved).
But maybe there is more pragmatic solution which would work well enough? For example we two can both agree now, that all events referenced in this thread happened one after another.
Each event could include a „suggested successor pubkey“ like the suggested relay. Increased occurrence in events referenced by friends would increase credibility of time order.
I have an idea and not sure how practical and applicable it can be.
The concept basically is a higher level key pair. We have now a public and private keys. Let’s add two more keys.
The first new key type is a MASTER key, which is a user’s (salt * npub * nsec) or randomly generated. The second key is a POSTER key, which is a public key derived from the MASTER key. Theoretically, a user can have infinite MASTER keys. However, a user may decide at any moment to choose and assign the new key pair. Assigning the new key pair requires the user to publish from the associated npub a possibly new kind event and advertise the POSTER key. This event is a one time irreversible event.
POSTER keys work as pointers and status checkers. They are the npubs managers and the identity keepers. They publish npubs with updatable tags or labels for self or others.
Example: I decided to generate my key pair today. I go to a nostr identity manager client. I enter my current nsec and login to generate a new MASTER pair and publish the event from my current npub. I then will be able to label my npub as active, revoked, expired or old… I could then generate new key pairs for any use case and tag them as such. I could also vouch to other’s npub’s essentially to build on the idea of web of trust.
This also can work with your idea of allowing other people to federate or co-manage identities or keys. I just thought of all this now. I could have overlooked some design flaws.
