yes, the only case it could work with unnecessary complexity is where you use a remote signer, each client maintains state locally, and you remove a client
in this case you can also do the following which is easier: rotate the secret used for encryption
post compromise recovery requires key rotation and really should have a context of a connection
the point about the stable identity is part of the problem, to do post compromise with nostr you have to add a new form of temporary identity called a conversation... the identity is revealed to participants in the process but it is not the identitity that is maintained during it
so, yeah, it depends a lot on client state and that's why all the signals and whatsapps and sessions and suchlike are in a shambles, and i don't think MLS fully solves the problem, it does provide a mechanism for maintaining per-discussion identity but it doesn't deal with the "and then" part of it
the only solution for this relates to relays holding state data, btw
and i've been saying this for quite some time, that relays should be able to be trusted to hold state data
part of the issue then is really about clients having a deterministic keychain as this is the only way to keep the data across instances without actually explicitly storing it on the client
