AT Protocol's resilience to internet censorship

[harrmitch]

While AT and ActivityPub both aim to strike a balance between centralization and decentralization, I notice that AT has a more centralization (the BGS/App View) to serve "big-world" functions. Can this be a concern regarding easier censorship, and what are AT's countermeasures? For example, if a government on a small country decided to ban Bluesky nationwide, they would just have to block the addresses of Bluesky and its APIs. Though user data for Bluesky, stored independently on thousands of PDSes, was always available, most of the population would still be practically cut off from the network. Mastodon, on the other hand, seems much harder to block, since the government would have to trace the addresses of thousands of servers independently to effectively block the network. How would this scenario be handled?

[bnewbold]

It is a bit of a mixed bag. Censorship circumvention was not a primary design goal for atproto.

On the one hand, yes, there are some obvious domains and services IP ranges to block that could be detrimental to broad accessibility to content in the bsky application (build on atproto).

On the other hand, the underlying data structures of atproto are content-addressed, and thus very amenable to re-distribution via alternative transports. For example, you could download many atproto repos to a USB thumbdrive, or cache on a phone, and then distribute them offline or p2p (eg, similar to secure scuttlebutt). Or, in a more traditional (and more accessible) setup, redistribute repo content via mirrors, proxies, and alternative network gateways, all while retaining the content-address / self-certifying properties. This kind of functionality is not currently built-in to the current bsky client app, but a third-party app could do it.