Let's say I make a post on Bluesky, which is decentralized. My post is very contentious. It is blocked by the moderators, and the moderation service can't be disabled on bsky.app. I am now invisible on bsky.app.
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.
> 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'm being a bit cheeky in the article's tone but I am fairly confident from discussions in the past that "But where are Bluesky instances?" is a common question which usually demonstrates a misunderstanding of the architecture where "having instances of an app" is seen as a measure of decentralization.
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.
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.
Web pages aren’t digitally signed, aren’t necessarily indexed by search engines, and there are ways to block bots with things like captchas. You also have much more control over the UI.
With a PDS, the replication happens first, before anyone reads it, and the UI is out of your control.
Maybe that’s okay, but people should understand the tradeoffs.
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.
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.
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".
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.
This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).
With ActivityPub, because running an instance requires hosting the data, the application, and dealing with all the subsequent scaling challenges, you kinda have to choose between being taking on active ops responsibilities or tying yourself to someone else's instance (which will probably be one of the bigger, more centralized ones).
If you decide you don't like an instance you picked and decide to move (unless things have changed) you're kinda stuck needing to start fresh.
With AtProto, it's trivial to jump ship to a different application platform and continue using your same identity. Exporting your data from a platform and self-hosting is a bit of a UX challenge, but at least it's possible.
As an example, I recently started using Tangled for the first time and was able to login using my existing bsky-backed domain (h14h.com). No need to create a new account or pick a new username -- it was as if I were already there. Then getting set up w/ self-hosting my git repos on a VPS was an afternoon of work at most, and it's just some backend service chugging away that I almost never have to think about.
The worst that will ever happen is I see a banner message in tangled.org saying something like "your repo is out of date and may be compatible with the latest version of Tangled", which I can solve by simply rebuilding & redeploying a docker image w/ the latest versions.
Granted, AtProto is definitely harder to wrap your head around architecturally. But actually interfacing it with a user is much simpler, IMO.
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.
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?
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.
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:
- 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.
> 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.
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?
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.
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?
re: censorship & moderation, the folks @ BlackSky have been active in building out an alternative moderation structure (alongside running PDSes & AppViews).
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Let's say I make a post on Bluesky, which is decentralized. My post is very contentious. It is blocked by the moderators, and the moderation service can't be disabled on bsky.app. I am now invisible on bsky.app.
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.
> 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'm being a bit cheeky in the article's tone but I am fairly confident from discussions in the past that "But where are Bluesky instances?" is a common question which usually demonstrates a misunderstanding of the architecture where "having instances of an app" is seen as a measure of decentralization.
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.
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.
> So, anyone who wants to index it gets a copy and you have no control over what they do.
How does this differ from scrapers hitting the blog directly?
Web pages aren’t digitally signed, aren’t necessarily indexed by search engines, and there are ways to block bots with things like captchas. You also have much more control over the UI.
With a PDS, the replication happens first, before anyone reads it, and the UI is out of your control.
Maybe that’s okay, but people should understand the tradeoffs.
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
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.
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.
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
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.
If that becomes a massive problem - host a relay with different moderation policy.
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".
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.
This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).
With ActivityPub, because running an instance requires hosting the data, the application, and dealing with all the subsequent scaling challenges, you kinda have to choose between being taking on active ops responsibilities or tying yourself to someone else's instance (which will probably be one of the bigger, more centralized ones).
If you decide you don't like an instance you picked and decide to move (unless things have changed) you're kinda stuck needing to start fresh.
With AtProto, it's trivial to jump ship to a different application platform and continue using your same identity. Exporting your data from a platform and self-hosting is a bit of a UX challenge, but at least it's possible.
As an example, I recently started using Tangled for the first time and was able to login using my existing bsky-backed domain (h14h.com). No need to create a new account or pick a new username -- it was as if I were already there. Then getting set up w/ self-hosting my git repos on a VPS was an afternoon of work at most, and it's just some backend service chugging away that I almost never have to think about.
The worst that will ever happen is I see a banner message in tangled.org saying something like "your repo is out of date and may be compatible with the latest version of Tangled", which I can solve by simply rebuilding & redeploying a docker image w/ the latest versions.
Granted, AtProto is definitely harder to wrap your head around architecturally. But actually interfacing it with a user is much simpler, IMO.
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.
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?
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.
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.
> 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 ?
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.
You need a relay unless you want to have all the same NxM scaling problems as Mastodon.
Mostly because having a big centralized firehose relay is less decentralized than people want to admit.
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:
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Fatproto.afri...
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh...
Why is that a problem if you can host relay for $50 per month as TFA mentions?
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-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.
> 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.
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?
There are many relays, here's a list of 13 but it's not comprehensive: https://tangled.org/firehose.club/community-firehose-list/bl...
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.
You're right, I was probably confusing appviews with relays.
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?
re: censorship & moderation, the folks @ BlackSky have been active in building out an alternative moderation structure (alongside running PDSes & AppViews).
Nobody asks _how_ are all the Bluesky instances :(
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.
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.
"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."
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?
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.
> So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
Which host?
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
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.
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.
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.
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.
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?
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.
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.
There are multiple Bluesky AppViews, Blacksky has a totally independent one. And there are multiple relays, each capable of serving a firehose.
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 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.
> 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.
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.