> 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.
INTPenis 13 minutes ago [-]
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.
tao_oat 9 minutes ago [-]
I'm not sure there is such a thing as "true" decentralization :) In my mind it's more of a buffet of tradeoffs rather than a single sliding scale.
FWIW, in the AP world there are several individuals and small teams running relays/mirrors/caches/AppViews and so on -- but you're right that this could get more expensive as things grow.
muglug 44 minutes ago [-]
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.
Yeah, Relays are one way to do that. I've mostly skipped them because they're an invisible optimization and there are other strategies. E.g. many smaller apps today rely on Constellation (https://constellation.microcosm.blue/) instead of building their own database index, so they don't use a Relay at all.
RobotToaster 30 minutes ago [-]
They do remove content directly from relays. They claim they only remove content that is illegal to host, but I don't know how true that is, and there is always the risk it could change in the future.
I want the bsky org to be able to choose what content they host (and I think the internet would be a better place without section 230 protections allowing hosts to ignore the content they distribute); the promise as I understood it was that relays could be hot pluggable. If someone stopped carrying content (maybe it was illegal in /their/ region and not yours) you could failover to another relay.
However there is very little incentive to mirror any of the firehouse if someone else is doing it for free.
chokolad 27 minutes ago [-]
If that becomes a massive problem - host a relay with different moderation policy.
skybrian 10 minutes ago [-]
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 9 minutes ago [-]
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.
AKSF_Ackermann 60 minutes ago [-]
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?
danabramov 32 minutes ago [-]
Author here!
I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.
A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)
Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.
chokolad 29 minutes ago [-]
> Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?
I wonder why you are vagueposting here instead of stating your position firmly. Maybe because you are afraid to be shown wrong, but who knows ?
uberex 52 minutes ago [-]
I just searched up Relay and I guess Relay is like Feeder in the analogy? I don't need it? And if I want it I choose one (many?) or run my own.
hooverd 40 minutes ago [-]
You need a relay unless you want to have all the same NxM scaling problems as Mastodon.
hooverd 42 minutes ago [-]
Mostly because having a big centralized firehose relay is less decentralized than people want to admit.
danabramov 28 minutes ago [-]
That's not true.
It's not centralized in any way that matters. The Relay Bluesky uses is open source, you can run your own for $30/month if you really insist on doing that, it's trivial to pool between multiple apps if you want to lower costs, and there are already a few independent ones you can just use directly now, for example:
Why is that a problem if you can host relay for $50 per month as TFA mentions?
47 minutes ago [-]
RobotToaster 38 minutes ago [-]
There's basically only one instance.
There's only one PLC directory.
There's very few full relays, none that I'm aware of that don't mirror bluesky censorship/moderation decisions. The same goes for appviews.
danabramov 16 minutes ago [-]
- 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-directory-org). Longer term the idea is for it to have a similar role to ICANN. Here's more on that: https://youtu.be/9z0z-Qu66yM?si=_8Dcw1M3VSKFGZhm&t=493
- Re: full Relays, they're easy/cheap to run, and you can run one yourself if you think the other ones are coordinating with Bluesky and don't trust their decisions. You don't need to depend on something else to do that.
tao_oat 5 minutes ago [-]
Most decentralized systems I can think of tend to follow a power law distribution (roughly) where one or a few platforms dominate. In the fediverse that's mastodon.social (or maybe Threads), in email that's Gmail, in AP that's Bluesky. I'm not sure this is unique to the AT protocol?
Bluesky's moderation actions are generally implemented as moderation labels which take effect at the AppView level. Sometimes they'll take down someone's PDS or censor from their relays, but I don't believe third-party relays are aware of those relay takedowns at all.
RobotToaster 24 minutes ago [-]
You're right, I was probably confusing appviews with relays.
timbray 38 minutes ago [-]
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.
danabramov 13 minutes ago [-]
Yea that's fair. My stubborn point is that Fedi is trying to do the right thing using the wrong technology, and the resulting tradeoffs in user experience are why it will always remain niche. I hope that more resources will eventually flow from Fedi-centered solutions to more independent stuff in the atproto ecosystem.
jrm4 22 minutes ago [-]
"Seems to have worked OK for email"
THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.
ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."
uberex 55 minutes ago [-]
Thanks! Your name makes me think of a funner pre-LLM time when Elm and Redux was new and cool. Great explainer!
axus 46 minutes ago [-]
So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
danabramov 11 minutes ago [-]
What kind of censor?
Whoever operates hosting can decide to ban someone from hosting. This isn't different from how Cloudflare would ban you for hosting something illegal.
Whoever operates an app can decided to ban someone from that app. This isn't different from how a forum moderator can ban you for something they don't like.
Whoever operates services in the middle may decide to ban someone for network spam/abuse, same as cloud services may do if you abuse their limits.
You can always try to host your stuff elsewhere, and you can always access the same network from another app whose decisions you prefer.
So it's basically same as usual on the internet, but each role is separate, and you can mix and match what works for you.
chokolad 25 minutes ago [-]
> So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
To be fair, from 2022. I would argue that moderation in Fedi is holding together reasonably well. There are a few popular instances that lots of people think are overly aggressive/purist in their moderation policies, but the people using them seem to like what they're getting.
bjkeefe2 1 hours ago [-]
If you're curious about atproto and feel like a n00b about it, this is a great place to start.
jrm4 24 minutes ago [-]
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.
danabramov 7 minutes ago [-]
I'd say atproto gives you a clear sense of what's tied to each of your identities — you can go and explore your repo in a browser. There's nothing to say your identity has to be "tied to a person" anymore than your Mastodon account on some server is "tied to a person". It's true atproto has a "scraping is the default, so expect it" vibe, whereas maybe you're arguing Mastodon allows security by obscurity?
HashThis 53 minutes ago [-]
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.
ChicagoDave 45 minutes ago [-]
This sounds like BlueSky without the user-directed self and grouped moderation tools.
That’s not censorship. It’s showing you the door if you’re a jerk.
And it sounds awful.
toomim 46 minutes ago [-]
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 2 minutes ago [-]
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 39 minutes ago [-]
There are multiple Bluesky AppViews, Blacksky has a totally independent one. And there are multiple relays, each capable of serving a firehose.
hooverd 41 minutes ago [-]
You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.
danabramov 2 minutes ago [-]
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.
Rendered at 18:08:04 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
FWIW, in the AP world there are several individuals and small teams running relays/mirrors/caches/AppViews and so on -- but you're right that this could get more expensive as things grow.
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
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
However there is very little incentive to mirror any of the firehouse if someone else is doing it for free.
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.
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.
I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.
An app can work without a Relay (like https://reddwarf.app/ does). There are caches like Constellation (https://constellation.microcosm.blue/) that you can just query directly.
A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)
Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.
I wonder why you are vagueposting here instead of stating your position firmly. Maybe because you are afraid to be shown wrong, but who knows ?
It's not centralized in any way that matters. The Relay Bluesky uses is open source, you can run your own for $30/month if you really insist on doing that, it's trivial to pool between multiple apps if you want to lower costs, and there are already a few independent ones you can just use directly now, for example:
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Fatproto.afri...
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh...
There's only one PLC directory.
There's very few full relays, none that I'm aware of that don't mirror bluesky censorship/moderation decisions. The same goes for appviews.
- 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-directory-org). Longer term the idea is for it to have a similar role to ICANN. Here's more on that: https://youtu.be/9z0z-Qu66yM?si=_8Dcw1M3VSKFGZhm&t=493
- Re: full Relays, they're easy/cheap to run, and you can run one yourself if you think the other ones are coordinating with Bluesky and don't trust their decisions. You don't need to depend on something else to do that.
Bluesky's moderation actions are generally implemented as moderation labels which take effect at the AppView level. Sometimes they'll take down someone's PDS or censor from their relays, but I don't believe third-party relays are aware of those relay takedowns at all.
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.
THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.
ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."
Whoever operates hosting can decide to ban someone from hosting. This isn't different from how Cloudflare would ban you for hosting something illegal.
Whoever operates an app can decided to ban someone from that app. This isn't different from how a forum moderator can ban you for something they don't like.
Whoever operates services in the middle may decide to ban someone for network spam/abuse, same as cloud services may do if you abuse their limits.
You can always try to host your stuff elsewhere, and you can always access the same network from another app whose decisions you prefer.
So it's basically same as usual on the internet, but each role is separate, and you can mix and match what works for you.
Which host?
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.
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.
That’s not censorship. It’s showing you the door if you’re a jerk.
And it sounds awful.
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.
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.