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.