41–50 of 327 posts
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.
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.
In atproto, you can swap hosting (without changing apps), and you can create and use different apps (without changing hosting). That's the thing you can't do in Mastodon because it hard-couples hosting + apps into monolithic "instances".
In Mastodon, "receiver" and "sender" talk to each other, as you say. In atproto, hosting servers never talk to one another. The data from them flows into apps.
You're right that there's often a firehose in the middle, but that's also misleading. There doesn't have to be one firehose — there's a bunch of community-ran ones. It's relatively cheap to run one yourself these days (about $30/mo). It's easy to pool them between apps. And many apps don't use Firehose at all, and instead query community indexes like Constellation (https://constellation.microcosm.blue/). So "one firehose" is misleading.
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.
You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.
Running an AppView for your own app is not expensive at all. It can be as cheap as you want. It's only expensive if you want to store gigabytes of Bluesky posts and serve them to millions of users — i.e. if you want to build the full Bluesky AppView. But why would you want to build a Bluesky AppView? That's part of what I'm alluding to in my article — atproto isn't "for Bluesky". You can build any social app.
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.
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 tha…
How does this differ from scrapers hitting the blog directly?
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.
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.
- There's no "instances" so I don't know what you mean by this. - Re: PLC directory, indeed, there is only one of those. I think this is a legit point but it's worth considering the whole point of PLC directory is to be the single minimal stateless open source part that lifts identities out of apps and hostings. PLC governance and maintenance is being spun out into a Swiss organization ( https://atproto.com/blog/plc-…
And since that sounds like a massive centralization problem, how do we have a dozen more of them with independent governance that aren't all controlled by either the same legal entity or by whoever has legal leverage to compel that entity?
Earlier quoted context omitted.
You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.
Running your own firehose is not expensive, fwiw, it's $30/mo. If I were making a "serious" app I'd probably do that. Otherwise, relying on community-maintained ones seems fine. Running an AppView for your own app is not expensive at all. It can be as cheap as you want. It's only expensive if you want to store gigabytes of Bluesky posts and serve them to millions of users — i.e. if you want to build the full Bluesky…
The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.
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".
> 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 spe…
My article was an attempt to dig at this specific misunderstanding by comparing it to "But where are Google Reader instances?" which I think illustrates its absurdity. I genuinely do think that the two pictures I provide close to the end clear this up in a way a lot of early atproto/ActivityPub discussions completely gloss over.
Re: Relays, I wrote here on why I didn't include them: https://news.ycombinator.com/item?id=48600963. They're kind of incidental perf optimizations rather than essential to the model. In the post, I wanted to focus on the model.