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.

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.

... can be just a fallback for when nothing else works (just delete my key).

The key insight here is that people become used to the practice of from time to time, scanning the network for some special events that signal that some keys may have changed, and then they stop following the old one and start following the next. This can be done inside their main social app or on a standalone app or website.

That's also a good solution.

Isn't that a way to shard keys?