Recovering identities from pod disaster

When a pod loses its users' private keys, their identities become unusable. Forever.
The only thing a user can do is to create a new identity, because there is no way to ever reuse the old one.

This is an usability problem that has prevented me from having anything to do with diaspora, for two reasons:

• Some users (me in particular) really care about that relatively meaningless string called the identity (in the form of user@pod), their login, their email address, etc.
• Making a resource unusable forever is not going to be healthy for the network as a whole. This breaks the network a little, and it will not ever recover from that breakage. Bad things happen, and as diaspora grows, they will happen more.

No other protocol I can think of suffers from this problem. Centralized protocols simply provide a way to reset a password. Decentralized protocols either don't sign messages (like email), don't bind resources to keys (like email with pgp, because you can have multiple keys for one email address), or provide a way to inform that the user's key has changed, and re-validate it (like signal).

Diaspora tries to ensure that users (or their pods) are in control of their activity, to the point that without their keys, they can't even delete their accounts, as it might be considered censorship (and in some cases it certainly is).

However, by design, it also binds the identity to a key, and does not allow to rebind it to another one in case of a disaster.

I'd like to discuss the possibility of creating a method of reusing identities, that can be considered secure enough for users. Of course, any method allowing to bind another key to an identity will be strictly less secure than not doing that, but security is not the only thing important in diaspora. Usability is one of the others.

My initial idea is to trust the domain controlling the pod. Right now, someone controlling the domain can impersonate the pod however they want, and the only thing they cannot do is impersonate the users. They can, however, create new users, thereby wasting resources of the pod forever.

It can be argued that in some cases, it would be easier for an attacker to gain control of the domain than of the server a pod is running on, and it's a valid argument. We could, however, check the pod's SSL certificate. That way, if the podmin would like to secure themselves from an attack on their domain, they could utilize HTTP Key pinning to instruct other pods not to trust other SSL certificates.
Other podmins, who prioritize disaster recovery over that particular security mechanism, might simply not publish HPKP headers.

I think that this solution's usability benefits outweigh the security drawback of allowing key replacement at all.

To summarize, the only thing that I'd like to be possible in diaspora is reusability of identities in case of pod disaster. So I'd like to discuss how that can be done, and if there's will to do it at all.