The DM/notification thing is tricky. It can become very complicated with subkeys. And we hate complications... :)
Discussion
Are notifications tricky? The DMs are harder, though do people really want to receive them on every client? And KISS, but maybe subkeys don't need to be hard? If you already support deletion (for renunciation), you're most of the way there.
Imagine the mess that is a revocation record that exists in one relay but not on another. Half of your friends see your main account as active and the other half misses it and fall for an attacker's scheme.
Then sum that with the fact that you can delete the revocation record itself (or put an expiration date) and revert the position you had before in the app. Users confused everywhere.
Now imagine that with users having to migrate relays from time to time because of censorship. Some records can stay in the old state because paid relays don't allow you to update them.
Now imagine that mess when an attacker gets hold of your nsec and starts publishing events in the past. Keys that were supposed to be part of yours are not there anymore and vice versa. Old content disappears and new content comes up to all your followers, but depending on which relays they are subscribing to, the changes are different.
It's a mess.
Same as deletion. Same as anything really. We could put revocations in your profile, and then you'd have to argue that people won't realize this random npub isn't YOUR random npub because they couldn't load your profile 🤣
It's not the same. Yeah, you can make a mess with deletions today, but adding key revocations adds an order of magnitude of additional mess. It's way more complex. The attack space and thus app complexity grows.
I guess I'm missing something then. If you support deletion, my proposal allows revocation using the same mechanism. The only difference is that it's deletion of all events by a pubkey, instead of one specific event.
Yeah, that's the problem. It's a semantical difference. Instead of clients just needing to worry about one key for each follow, they now need to wipe and re-download large event sets when sub keys move. I can even imagine a DDoS attack purely based on revocations status changes.
My 102 proposal uses a single identity key, and the ability for any key to sign on behalf of the identity if it has an attestation. When you get an event, you immediately know whether it's authorized to impersonate the identity key, so you just treat it as the identity pubkey. If it's revoked, you delete the event, just as you would with a deletion request. So, everything operates as it did before (following one pubkey), except you can issue new keys without telling anyone, events signed by them look like you, and if you get burned, you delete all those events.
That's exactly the problem I described. I think you are underestimating your proposal's real impacts on clients.
For instance, what happens if a replaceable event has an attestation that keeps changing to different identities every second? If you add those attestations to NIP-51 lists, now apps are immediately reacting when the list options change, all relay filters change, the whole web of trust ranking keeps switching.
That's an interesting case. I don't think this will happen in correct implementations because either the replaceable event will be treated as the identity key (having implemented 102), or the signing pubkey (having not). Either way the identity of the "current" event won't change, even if the signing key uses rotating attestations.
Key management is definitely a big deal, and in distributed systems rather intimidating. But having worked on SSO in the past, the current situation is risky and holding nostr back. Fixing it won't be easy, but doesn't need to be complicated if we work out the details.