> 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.

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".

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.

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

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.

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?

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.

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.

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.

Thanks! Your name makes me think of a funner pre-LLM time when Elm and Redux was new and cool. Great explainer!

So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?

If you're curious about atproto and feel like a n00b about it, this is a great place to start.

Semi related post on why the moderation of federated Mastodon instances is a problem: https://blog.raed.dev/posts/mastodon_moderation

https://JFKSocial.com/ is a full Twitter (X.com) clone that works on BlueSky. It is new and launched.

Open source. BlueSky + Mastodon + NOSTR. Advanced feed algorithm. 100% of the code base is open source (in 2 weeks). https://m.jfksocial.com/

It makes the feed rank algorithm metrics clearly visible on the right bar. People can confirm they aren't being censored or deboosted by seeing their own scores made transparent.

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.

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.