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.
Discussion
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.