On the reliability issue, from my very quick skim, my kneejerk reaction is that I do think that the Fediverse might need some improvements in dealing with resillience due to instances going down permanently. As it is, that happens – due to hardware failure or financial concerns or God knows what – the accounts aren’t available.

One possibility might be providing a pubkey method to prove that a user is legitimately a user on an instance that went down. Publish a pubkey prior to an instance failing, and then permit a “transition to a new account” mechanism where a user can prove to the system that they are an older user. Key management – storing and retaining a private key – might be a bit of a pain without a third-party app, as I don’t know if there’s a convenient way to do that in browsers today.

Another might be having some mechanism to deal with node failure. Freenet deals with having a fundamentally-unreliable distributed storage mechanism by having a level of forward error correction and then distributing some redundant data around the network so that it’s possible to regenerate a certain amount of lost data when a node leaves the network from the data on remaining nodes.

As it stands, I don’t think that lemmy/kbin have something like that. They must retain copies of some of the data – hence the “The magazine from the federated server may be incomplete. Browse more on the original instance” message that kbin shows if I’m looking at a community on lemmy.world from kbin.social. But unless it’s cryptographically-signed by lemmy.world, if lemmy.world vanishes forever, kbin.social cannot prove that its copy of data originating from lemmy.world is authentic, so it cannot be made re-available to other lemmy/kbin instances.