There are no instances in ATProto

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'm not saying ATProto is bad at all, but I feel like this blog post adds more confusion than it clarifies anything.

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

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

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.

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.

Now, sure, you can use a different instance for most of these services. And that instance can interoperate with Bluesky. But that's the case for Mastodon as well, and the real difference is the Fediverse has had to live with the painful compromises that come with the anarchy of the real world. I think Bluesky will discover its own version of defederation soon enough. I don't think “ah, but you technically theoretically can still interact with people even if you can't see them on your instance” is worth all that much.

So at the protocol level it’s decentralised, but in practice the system is still very centralised (in terms of who controls it).

Not saying this is necessarily Bluesky’s fault, but it’s how things have played out so far right?

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.

Atproto apps are not like an RSS reader that runs on the users' computers and connects directly to the sources of content.

Atproto apps are servers that control, filter and shape the content they serve to readers.

Atproto apps can censor, shadowban, show ads, algorithmize the feed into anything it wants. The user is powerless and the creator is a victim that can't do anything besides crying.

The fact that any person can host their data anywhere is completely meaningless since they have no way of distributing that data.

If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage; like, I can see how Mastodon keeps chugging along no matter what companies get sold to who, but I don't see how ATProto survives the death of Bsky.

Another way to look at it: the Twitter-brained perspective is that it's a good thing to build a system where everyone has access to everyone else all of the time - that the global firehose is a primary goal.

That notion is not universally agreed upon as desirable. Some folks and groups of folks value membranes with varying degrees of permeability.

With Mastodon, each instance is a self-contained community server with the option to link up with peers of similar shape. That this arrangement makes a whole-world view difficult is seen as a feature-not-bug by many users.

Also, since each instance is a self-contained complete unit of microblogging-shaped community, that means a relatively small technical team can host & maintain that unit for a decent-sized group of folks with relatively cheap cost.

Put a bunch of those together in federation, and you have a chance at a pretty well-distributed spread of moderators and caretakers. Depending on how any particular instance's funding and governance is setup, that can also result in members being more or less involved in the running of the place. (Which, also, is why some folks value being "belonging" to a particular instance.)

In ATProto, the "instance" is the complete stack you'd need to have ownership over the whole shebang. Some folks and communities value that. Versus Mastodon, Bluesky is just a much much bigger box.

You can also separate Mastodon from ActivityPub. You can make new apps atop ActivityPub - and folks are. Photos, videos, calendars, etc. It's based on JSON Linked Data, and that's expandable to other types of activities and data. If you really wanted to, you could make a great big all-encompassing app UX that handles everything. But, I guess no one's found that interesting enough for it to take off yet.

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.

It seems to be the nexus of federation + https://signal.org/blog/the-ecosystem-is-moving/

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.

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.

The main different is the designs Facebook has employed manipulated their users to adopt this "scroll down" method of reading. Each item of information is only displayed just a few seconds on user's screen, unless user stopped scrolling at the item they really interested in (and then maybe tap to open it).

That's not the same design used by blogs. Think of blogs as mini news sites, it encourages their readers to open the content in a full page to read it without interruptions. And, the readers has to calm their heats down to read long statements, this costs time and demands focus.

If you port the design used by blogs and apply it to display Facebook posts, that will be user-hostile, because user has to click each post only to read a potentially very short content.

The opposite is true too. You can't encourage user to "scroll down" a wall of long texts just to read the next wall of long texts, because that will be exhausting. You can't even create the anticipation that there's more stuff down, because that will just manipulates the user to keep scrolling down and skip.

That's why I think even you technically can aggregate blogs and social media in one app, you should probably be careful about it.

https://atproto.com/guides/overview

ATProto is "decentr-washing" as far as I'm concerned. Even if you self-host as much as possible, if Bluesky's relay declines to crawl your PDS, or its AppView declines to index/serve your records, then to essentially the entire audience you simply don't exist. did:plc controlled by a Swiss Verein, as if this could be a reason to drop all self-sovereignty worries! Credible exit was actually always working well on ActivityPub already, and if you self-host your instance you probably won't even need it anyway. Regardless, there is FEP-ef61 now, so I genuinely don't understand why to prefer ATProto over ActivityPub, even in the foreseeable future.

Let's not even talk about Nostr, that natively solves all the issues that ATProto seems to care about. Nostr is IMHO a much superior technology, unfortunately plagued by ecosystem/people and Bitcoin-dictated technical choices (BIP-340 keypairs, brrr).

When a user decides to jump ship from mastodon.social run by Mastodon gGmbH to another server, they are using a similar but different service. It has different moderators, different emotes, different themes, different federation list, etc. They all have a different flavour, and, for better or worse, they come in a single package.

When a user decides to jump ship from bsky.social run by Bluesky Social, PBC, first of all... what does that even mean? Do you want an alternative storage (PDS) for your data that will still be read by Bluesky the app and Bluesky the relay? Do you want a different "service" (what @ calls AppView) which is then not Bluesky? Do you want a different handle other than @[username].bsky.social? If that's the case, you don't even need to faff around with alternative PDSes or AppViews, you can just slap your domain on it!

Mastodon invites users to federate by giving it a character. Bluesky slices and dices it to a point where the only reason you would bother considering decentralisation is for ideological reasons. And to that point, Bluesky has consistently prioritised building their own service up rather than decentralising. You still can't export photos and videos you've uploaded (through their AppView). Until some time ago you weren't able to return to using Bluesky's PDS once you've moved away. And of course, because ATProto operates out in the open, features such as bookmarks that are supposed to be private doesn't even go through the ATmosphere. (I'd love to know if these are exported but I don't know of a way to open their ".car" file which is neither a plaintext nor a zip file.)

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.

ATProto making some idealistic compromises to improve the protocol as a product is a more effective half-court shot at the winning users from the oligarchy of apps than AP will ever be with its current design.

There’s a lot of talent in this community that could be spent building an ecosystem around the protocol far more likely to make a dent in social media centralization, but we’re stuck letting perfect be the enemy of the good.

Yes, are they? Where are the alternative hosting that do the same thing as Bluesky?

But you're just Mastodon-brained, you don't get it!

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.

What I'm most confused about is that an 'instance' has just shifted elsewhere. Sure, with AP you have to choose an instance, or just go with the default mastodon.social. AT doesn't seem to have instances but, you have to choose a host, and I suppose there's probably a Bluesky default host. I can't really see how that is any different. You probably could self-host an AT host as much as you can self host an AP instance for yourself (I run mine on a $6/month VPS).

The second point I don't quite get is that these apps don't seem to solve the same issues that instances do, and I believe this is the part where I'm lacking AT Protocol knowledge. If, in running my own host, I need to have software that handles access control, authentication, follows, etc, then I'm running an instance, even if it's called something else. If a host stores only data, then at some other place there is software that handles follows, access control, etc; then that software is equivalent to an instance, even if it's called something else.

When people ask where the AT instances are, I think about it like this: with mastodon (or any other AP app) I control not only my data, but the code that handles it. With ATProto what it seems like to me is that I can control where my data is, but not the code that handles it (considering the main criticism that you can't run bluesky 'instances', even if instances are called something else). That's why I think 'There Are No Instances in atproto' doesn't convice me. There might not be something called instance or it might be broken down in different components, but there is at least something equivalent. If you have a million different hosts but this data is handled by a single component hosted by someone, then you can't really say it's decentralized.

Sure, there are technical differences between both protocols, but from a user perspective without protocol knowledge, it doesn't seem any different from the outside. You download the app and use the default host/instance and if you don't want to be on the default one you have to get technical regardless of which protocol you chose.

One bit of feedback is that the somewhat 'snarky' comments directed at ActivityPub might put off the target audience of the post, that are precisely the people who ask where the instances are. But all in all, I feel the article did a good job of explaining the differences (besides the few points I mentioned earlier) and clarifying that ATProtocol has a clear separation between the data and the presentation of the data. While it's something that AP can do (my instance works with mastodon, with pixelfed, and other 'Apps' and my data is in a machine I control), it's not the default and data tends to be tightly coupled with the big instances.

I mean, that's how it went, after all. BS/AT is a fine replacement for twitpic-era Twitter, but it's not a locked-open decentralized social media.