What about the UX for managing all these keys? Every time you try a new app you must create a new key using your master key, so where does that master key live?

In an offline hardware device?, then it will be incredibly hard and only 5 people in the world will do it, everybody else will just paste nsecs and the protocol will be bloated for no reason.

Or in an online device or server that keeps running 24/7 and answering requests for creating new keys somehow? Now we have just recreated NIP-46 but 100 times worse.

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.