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.

▲

danabramov an hour ago | parent | next [-]

Sure, there are servers, but the different grouping is the whole point because they're not coupling hosting to apps. When people say "where are Bluesky instances", they're asserting that it's useful to run many copies of the Bluesky database server. My article is an attempt to show that this way of thinking is very Mastodon-brained because these "instances" are the only unit of decentralization that's available in Mastodon. But you don't have to think this way.

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.

▲

iameli 2 hours ago | parent | prev | next [-]

There are multiple Bluesky AppViews, Blacksky has a totally independent one. And there are multiple relays, each capable of serving a firehose.

▲

hooverd 2 hours ago | parent | prev [-]

You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.

▲

danabramov an hour ago | parent [-]

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

▲

JoshTriplett an hour ago | parent [-]

> But why would you want to build

The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.

▲

danabramov an hour ago | parent [-]

I don't understand how running your own Relay is related to competing with Bluesky. A Relay is just a dumb websocket broadcaster. Yes, you can absolutely run one on your own if you don't want to rely on any of the existing ones. I don't think this has to do with competition.

	▲	JoshTriplett an hour ago \| parent [-]
		I'm saying that if there is any required component of a full ATProto setup whose lowest-friction implementation is "use the One True Central Implementation, which every tool defaults to and which will be very painful to change", then it's not a decentralized protocol. Are there any components of ATProto that are found not through a service discovery mechanism that would seamlessly migrate to a new service, but by every individual app going "here's the hardcoded URL we never expect you to want to change"? I like the concept of working like RSS. I don't like the idea of having a massive ecosystem coordination problem with game-theoretic network effects, for any component of the system.