We should finally fix key rotation in Nostr.
I think this approach makes a lot of sense.
Let me know! nostr:naddr1qqgrydtrvyekywfev56nvdfjxsux2q3qklkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qxpqqqp65w2k68hy
Discussion
Let's say you want to rotate keys, because you suspect it's been compromized. I'm a user who follows you so I would like to know the new key
Who's social graph does my client use to know the new key? If it's yours, then that graph could have been altered after the key got compromized, so it's not reliable. If I have to rely on my WoT, then somehow the people that I follow/trust would have to overlap with the people that you follow/trust
Its kind of up to the client implementation.
But as you say, in a compromised scenario we cannot trust relay lists, follows etc of that key.
The client could display all attestation events, with highlights for higher wot keys and follows / follows-of-follows. Arguably more information is better here, the algorithm can be simple or sophisticated.
https://git.nostrdev.com/mleku/next.orly.dev/src/branch/main/docs/names.md
nostr needs a consensus mechanism for this kind of thing. this is a design i have made that runs a name service, storing consensus state on nostr and using nostr ephemeral events for rendezvous connections to simplify for node runners at home to use relays to enable inbound connections to the FIND daemon without needing to run it at a data center.
the specifics are different for the use case of key rotation, but i think something along similar lines could help create a consistent data set for the implementation of this key succession process for the case of compromised or lost keys.
the thing that is important for me to point out is that the consensus is not a strong consistency consensus, deliberately, to make it harder to poison from any given node on the network. it achieves this by using user-assigned trust relay to relay, and social graphs to calculate whether or not, according to their trust attestations, new name registration/transfers are trustworthy. so sometimes some nodes won't have all the same data, if dodgy operators show up and relay operators say as much in their attestations of the new nodes, their proposals will get mostly disregarded, and not be able to poison the consensus.
the same things would apply to a key succession system. there would be attack vectors involving this since especially, one of the use cases is recovering one's position in the social graph in a semi-automatic fashion.
Why do you think we need absolute consensus on this?
bitcoin's consensus is stronger than the design i just showed you. it is a consensus with probabalistic consistency, which means that with time, the chances of forking the chain from a given height dwindles to practically zero at 6 blocks.
this is a weak consensus, by design, that makes infiltrating the graph and getting other nodes to accept bogus events (eg like the thief who stole your npub trying to rug you of your social graph), very difficult. it requires a high level of coordination to break a consensus like this because you have to recruit the supernodes in the denser pockets of the graph, in order to poison the data.
I feel that choosing which key to rotate to is such a nuanced question that gaining a global consensus is near impossible, and that's alright.
What do you think of Frost? https://www.frostr.org/
Good tech, but doesnt ultimately solve secret loss or or compromise.
would something like this built on nostr help with attestation? https://open.codeword.app/
just thinking you could do offline, "human 2fa", for people to verify they are are who they say they are
I guess this can be mentioned in the verification method.
I have been thinking about this recently. Thanks for sharing