There are no instances in ATProto
danabramov
397 points
208 comments
June 19, 2026
Related Discussions
Found 5 related stories in 111.8ms across 10,996 title embeddings via pgvector HNSW
- I'm betting on ATProto speckx · 101 pts · March 30, 2026 · 60% similar
- At Protocol: Building the Social Internet resiros · 78 pts · April 29, 2026 · 49% similar
- Cirrus: ATProto Personal Data Server That Runs on Cloudflare Workers gurjeet · 12 pts · June 20, 2026 · 44% similar
- Ask HN: Is anyone using the A2A protocol? asim · 75 pts · June 18, 2026 · 39% similar
- Show HN: Mtproto.zig – High-performance Telegram proxy with DPI evasion slp3r · 12 pts · April 03, 2026 · 38% similar
Discussion Highlights (20 comments)
bjkeefe2
If you're curious about atproto and feel like a n00b about it, this is a great place to start.
Raed667
Semi related post on why the moderation of federated Mastodon instances is a problem: https://blog.raed.dev/posts/mastodon_moderation
AKSF_Ackermann
I wonder why were relays mentioned only mentioned in passing and there was no elaboration on how they interact with the rest of the network. Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?
uberex
Thanks! Your name makes me think of a funner pre-LLM time when Elm and Redux was new and cool. Great explainer!
axus
So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
toomim
AT does have instances. They are just grouped differently. In BlueSky, there is only one single "AppView" instance in the entire network. There is one instantiated "Firehose". Each user can instance his own "PDS". In ActivityPub/Mastadon, the instances are "sender's server" vs "receiver's server." The difference isn't that there aren't "instances" in AT proto. It's just that the instances are segmented differently.
muglug
As far as I can tell, Relays[1] are the glue that makes ATProto work performantly. I think they're supposed to be content-agnostic — they just shuttle data through, reducing the number of services each AppView needs to be aware of. As the blog mentions, the big improvement vs Mastodon is that Relays, AppViews and PDSes are separate services with their own distinct scaling demands. It's a rather beautiful solution to a system design problem. [1] https://atproto.com/guides/glossary
timbray
ATProto is an interesting protocol and there is lots of room to argue about its plus and minuses (and about Fedi/Masto's), but lots of people are already doing that so I won't. My concern isn't technology or culture, it's money. At the moment, ATProto is existentially dependent on Bluesky PBC, a venture-funded startup ($100M from Bain Capital). There are people doing good work to make it more decentralized, more power to them, but at the moment it's still deeply centralized. And it's hard to see what the business model is that will support what Bsky PBC does at a global scale. Eventually Bain will want to see a revenue stream that justifies their investment; maybe there's a way to do that that doesn't involve enshittification but it's certainly not obvious. You can dislike the instance-centeredness of Fedi/Masto (seems to have worked OK for email over the decades) but it's an actual thing that's actually working. And offers account migration without losing followers if you don't like the instance you're on. And has multiple really excellent client software packages. And seems to be covering its costs through a mixture of Patreon, co-operative & nonprofits, some Euro-gov help, all without any VC input. It can't be bought or owned by anybody. Put another way, this is a really interesting space. But the technology is less interesting than the culture, and the culture is less interesting than the m money.
RobotToaster
There's basically only one instance. There's only one PLC directory. There's very few full relays (edit: appviews), none that I'm aware of that don't mirror bluesky censorship/moderation decisions.
jrm4
Yes, and this is exactly why ATProto is worse and more dangerous. Instances are safer. precisely because they are more genuinely decentralized. The ability to forever tie your stuff to a person, strongly, is exactly what the surveillance state would want. Mastodon's model gives you plausible deniability. It's safer.
INTPenis
ATproto sacrifices true decentralization for consistency, Mastodon and AP does the opposite, sacrifices true consistency for more accessible decentralization. At least that's how I understand it, because running an AP node is much more accessible to regular selfhosters than running one of those content relays in AT. So all you'll ever "decentralize" in AT is your own data, it's more about owning your data rather than collectively owning a part of the network. And we've been over this many times before on HN.
skybrian
An important distinction is that blogs have their own websites and they're not required to publish full articles in their RSS feed. Bluesky doesn't normally work that way - everything in the PDS gets replicated. They are also encouraging people to put put full blog posts in the PDS for easy replication. So, anyone who wants to index it gets a copy and you have no control over what they do. You don't have to do it that way, though. You can publish your blog on your own website and just publish links to it on Bluesky.
WorldMaker
Google Reader feels like an ominous pick for an analogy. Sure, RSS survived the Google Reader shutdown, but not all the communities that used RSS (many that still don't know what RSS is) survived. It feels almost "Freudian" to claim a thing is decentralized and then by analogy keep pointing to a massive (social) centralization of a decentralized ecosystem as a good thing. But especially one that we already know the ending for. Google Reader united a lot of RSS houses, value added a social graph and social commentary between them, and then at the whims of executives Google Reader fell and nearly killed RSS, but certainly destroyed an impressive social graph. As an analogy that doesn't give me a lot of confidence in ATProto.
1dom
> Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly. I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto specifically at the expense of ActivityPub (and RSS, a bit). I think you lower yourself by doing this: 1. it forces you to omit and contort the interesting technical truths about ATProto and Activitypub, like Relays and their pros/cons for ATProto and account migrations and pros/cons for ActivityPub 2. it creates unnecessary conflict and criticism and seems unnecessarily divisive for 2 platforms solving problems in such a similar space It's also just seems a bit silly: why would you assume that when someone asks "where are the instances?" they're not using the common mainstream use of the word "instances", like, servers, or running software, or VMs, or containers? Sorry if this is overly harsh or I've misunderstood, but it gives me a strong vibe that it was motivated by disdain and frustration towards ActivityPub and ActivityPub users rather than wanting to legitimately inform the world about ActivityPub. I did enjoy the diagrams and the explainers though! I just felt like the subtle digs and pops at activitypub were an unnecessary distraction.
JoshTriplett
I appreciate how this explains the difference between the two. But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve? For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto solve the problems that defederation solves?". Because the default reasonable answer to assume, given this framing, is "it doesn't".
rzzzt
Nobody asks _how_ are all the Bluesky instances :(
jchw
Let's say I make a post on Bluesky, which is decentralized. My post is very contentious. It is blocked by the moderators, and the moderation service can't be disabled on bsky.app. I am now invisible on bsky.app. So when this happens where do we go? Forget about "instance brain", your problem is Bluesky is vastly more centralized in practice than the theoretical marketing. Because if it was truly practically decentralized you could actually point to numerous instances of the service, but last time I raised this point there were... 3. Except one of them was actually not running the full appview and we weren't 100% sure the other one was either. I'm sorry man, but this isn't going to cut it. A lot of people are absolutely right to not be sold on ATProto as it stands: there is no obvious reason to believe it will become more meaningfully decentralized over time rather than less. As it grows larger, the feasibility of having more "instances" that can run completely independently of Bluesky PBC becomes even less plausible. If over 99% of the users are using Bluesky PBC infrastructure and placeholder DIDs, almost all of the keys to the kingdom lie in one place, and at that point you have invented Twitter with a ridiculous number of extra steps. Can you explain to me why I would ever run my own PDS? Why would I pay to selfhost stuff while allowing someone to control almost everything I can see and do? Unfortunately, this will never get answered. It's very easy to write a long blog post explaining how ATProto is technically decentralized. It's much harder to unpack how it actually isn't really.
cavoirom
One thing I like about the ATProto is the stable identity, I could change the hosting as the author did recently and the other users see no difference. The one down side of the system is the cost. It's cheap to host a PDS but expensive for other components. Users could not relies on "someone" for running those components for free forever.
MBCook
When the first paragraph starts out by insulting people for not using the exact jargon you want them to, it really doesn’t make me want to read the rest.
threetonesun
I feel like the charts could be clearer if they showed the primary user experience difference between RSS and AT/AP, which is how do the arrows flow for Bob's response to Cat's post. I understand it fairly well for AP, I don't think I actually get it for AT.