I completely understand your point, but it's not what I was trying to convey. I'm thinking about how we can create a more robust security model for accounts, ensuring that users can maintain their reputation, wot, and at the end the value of their account. My idea is not to have one subkey per device, but rather to have a master keypair and an active subkey (which can be improved upon in the future to accommodate more use cases, but for now, let's focus on one master key and one subkey). The master key becomes the source of truth and designates a subkey as the current one in use. In the event that the subkey is compromised, the master key can inherit the reputation and data generated by the subkey, serving as a kind of backup and support. The user can then migrate to a new subkey and update the master's metadata to attest to the new subkey in use. This approach maintains reputation and aggregates it in a single, well-known source, while also solving the poor user experience of rotating public keys. Currently, the most frequent way i've seen people dealing with this case, is publishing a kind1 message telling everyone, which is often only published once, making it likely that a significant portion of contacts will miss the update. This new approach would improve upon that, but its just an idea tbh.

Replies (3)

The ux would remain largely the same as it is today, since the master keypair wouldn't require frequent interaction, making it suitable for cold storage use cases. The only additional steps would be to attest the relationship between the keys initially, and in the event of a catastrophe or key rotation, where the master keypair would voluntarly inherit the reputation and value of the rotated account and attest to the new one. View quoted note →
The idea is the same in that you end up with multiple pubkeys or you re-broadcast with the new key all your past events. But, key compromise always happens at some point and that is a good argument to isolating these points so in a nostr where everybody has multiple pubkeys, people would like to use different subkeys for different points or apps or machines. But as fiatjaf pointed out, this problem is sort of solved with nsec bunker as here, the master key controls how the key can be used and you can give sort of sub keys to different systems without third parties needing to care or know about these sub keys.
Yea, but then you make everyone rely on 3rd parties bunkers, or push them to run a server 24/7. Also in that way subkeys will pollute relays since they are just made to trigger the bunker and get a signature from the master pubkey