> Maybe ignoring the AT protocol so I (and others?) can get a better sense of how such systems might be employed to ensure that an arbitrary organization can bu

> Maybe ignoring the AT protocol so I (and others?) can get a better sense of how such systems might be employed to ensure that an arbitrary organization can build defenses against themselves becoming adversaries (seems like a fairly useful mindset in general). There are ways to do this, but being trustless in the context of a social network is a thorny problem I'm not sure I can provide an answer to. The whole purpose of such networks is to enable communication with people you may not necessarily know (or trust). Furthermore, you implicitly trust the medium in which you use to communicate (BlueSky, Twitter, SMS, Zoom, etc.). There are ways to make things difficult for a service provider; you see many of them in high security contexts. For example, when storing data on AWS GovCloud or similar, you have the option have AWS use user or company provided encryption that they do not have control over. Should AWS be compromised in some way, they would still need to have your cryptographic keys in order to access unencrypted data (https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/Server...). Another approach is message signing. An example of that is PGP signing of emails or files. You can use these cryptographic signatures to verify a message (email) or binary blob (file) has not been tampered with. Another common approach, which you have alluded to, is some kind of multi-party scheme. Many cryptographic blockchains are good examples of this: You need a majority of parties in such schemes to agree on something for it to be considered valid or true. A combination of these things can be used to make it more difficult for a service provider to be compromised or act against their user's interests. Sadly, this does not make it _impossible_ for them to do so. A user or customer who doesn't want to tolerate the worst case scenarios here still needs to make their own back ups, decide what entities to trust, and ensure they have robust procedures for doing things like trusting new entities or managing cryptographic material. I'll also note that there are in fact live examples of such systems if you look for them. See IPFS for one such example: https://ipfs.tech/ https://ipfs.tech/