key rotation is definitely one of those deeply important problems that we haven’t solved yet. I believe WoT is the missing ingredient that has prevented any workable solutions. Of course there are technical tools that we also need. But I’d love to see key rotation be one solution that emerges from our WoTathon.
There will be more than one way to do it. We should start with a solution that is as simple as possible and can work. Ideally, it would be a solution that we can build upon over time.
I imagine a simple solution like this: suppose Alice decides to rotate from npub1 to npub2. We can focus on solution for a compromised nsec as the primary use case for key rotation, although in theory she could have some other reason for key rotation.
The basic idea is that in meatspace, she tells people that her nsec is compromised, and she asks them to publish attestations to that effect. Presumably, she would also want the public to know her new npub and the timestamp when the rotation takes effect.
Ideally, this would be as simple as possible and still work. Luckily, the Decentralized Lists NIP provides a method to implement the above idea. No need for a new NIP; just make a new decentralized list! The new list would have three required fields (specified as required as per the DL NIP): old (compromised) pubkey, new pubkey, and timestamp when it takes effect. All of Alice’s
This would be an awesome entry for the #wotathon: a NostrKeyRotation client where Bob can go and publish an attestation (an item on the list described above, a kind 9999 event) that Alice’s npub is required, and then Charlie, Dave, etc can either publish identical events, or — even better — they can do a reaction to Bob’s event as confirmation. Then the NostrKeyRotation app uses personalized trust metrics to keep track of rotated keys, maybe publishes them in some format that can be consumed elsewhere in nostr.
What do you think?
NostrHub
NostrHub | Discover and Publish NIPs
Explore official NIPs and publish your own custom NIPs on NostrHub.
