There are no instances in ATProto

Most of the useful discussion agreed that this is a real architectural difference, and that the separation is ATProto’s main idea. Several people pointed out that the split gives ATProto a cleaner path to account portability, user-controlled hosting, and cross-app reuse of the same identity and social graph. A user can move their PDS without changing apps, or try a different app without abandoning their account. Others stressed that this design also avoids Mastodon’s server-to-server mesh, where every instance talking to many other instances creates scaling and moderation headaches. But the comments kept returning to what the post leaves unresolved. The common question behind “where are the instances?” is not really about vocabulary. It is about who controls the experience if Bluesky the company disappears, censors you, or remains the default host for nearly everyone. On that front, the room was much less convinced. Right now Bluesky hosts the overwhelming majority of user data, runs the dominant app, and anchors most of the network’s practical reach. That means ATProto’s modular architecture does not yet translate into broad operational independence. The strongest defense was that the protocol still changes the failure mode. If an app dies, another app can index the same public user repositories. If a host turns hostile, users can in principle move. If one app moderates you out, another app like Blacksky can show the same account differently. Critics replied that this is only meaningful when there are enough independent appviews, relays, and hosts to make those exits realistic, not just theoretically possible. Relays became the flashpoint because they sit right at that gap between theory and practice. Some commenters argued the article was misleading for downplaying them, since they are the easiest way for app developers to consume the full network and therefore one of the places centralization can hide. Others countered that relays are not fundamental in the same way as hosting and apps. They are an optimization, they are much cheaper to run than earlier discussions assumed, and apps can also use shared indexes like Constellation or directly subscribe to PDS streams. The practical consensus was narrower than either side wanted. Relays are not “instances” in the Mastodon sense, but they are one of the real infrastructure choke points that determine how easy it is to build an independent app at scale. Moderation was the other missing piece people wanted made explicit. ATProto does not replace defederation with magic. It moves moderation into different layers. Hosts can refuse illegal content, apps can choose what to show, and the protocol includes app-agnostic labeling primitives so outside moderation services can plug in. Supporters saw this as cleaner than instance-wide defederation, which often gives server admins too much power over who users can talk to. Skeptics said the practical effect still depends on who runs the appview people actually use. If almost everyone is on Bluesky’s app and Bluesky’s hosting, then being filtered there feels a lot like being banned from a centralized platform, whatever the protocol says underneath. The thread landed on a blunt conclusion. The post is useful as a topology explainer, especially for people who assume every decentralized social system must look like Mastodon. But it does not settle the more important question of decentralization in practice. ATProto’s bet is “decentralization by decomposing the stack” rather than “decentralization by multiplying communities.” Whether that turns into a robust ecosystem depends less on the protocol diagram than on whether independent hosts, appviews, moderation services, and full-network mirrors actually become common enough to matter.