> 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.
> 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?
Of course depends on the context, but in a lot of discussions about ATProto, ActivityPub, Mastodon and nearby areas, people talk about "instances" as in "ActivityPub instances that host my data and my profile uses its URL as a 'name'". The blog post is specifically for that context I think.
It's less about trying to hide around the issue, and more reframing how you see the concepts, as people start to associate words with concepts and structures. So when people talk about "decentralized social media", lots of people think about ActivityPub, which typically (always?) has a kind of federated architecture, and the instance is one of those nodes in the network. When these people see ATProto, instinctively (and perhaps rightly so) they literally ask "But why is there only one Bluesky instance that people join?" as those concepts map close to what they know.
Overall I think the post is a good and useful addition to the discourse, with perhaps not a completely novel perspective, but posted publicly for future reference when this inevitably gets asks again sometime in the future, specifically for the people who have these previous associations already formed in their head.
All of this goes away if we just do P2P social media.
Swarms of content.
Cryptographic identities and content signing/attribution.
Cryptographic hashes for content uniqueness/immutability.
Immutability in general.
Ephemerality (content lives as long as some node cares to retain it, otherwise it gets forgotten).
Concrete but extensible ontology for core concepts.
You don't need login. You don't need to agree on a common platform. 3rd party tools and extensions can filter content, provide trust graphs, interest graphs, etc.
You can just slurp up and score whatever might interest you. Your agent or algorithm might do pre-filtering against your preferred heuristics to downsample to relevancy.
You could write any client for this in any shape or form. Completely different look and feel for different people and interests / focuses.
Daniel Holmgren discusses this in his really good atproto ethos talk — the P2P networks are cool but incapable of delivering on what users expect from modern social media https://youtu.be/1A-0k58TfPo?si=f_d4uoz_I8kMoKDw
The problem with client P2P is there’s no aggregation at scale. You can’t even accurately calculate things like post likes. Not to speak of recommendations, search, and all other basic things people expect from social apps.
Atproto is an attempt to engage with the problem space in a way that hits the baseline UX of Web 2.0 apps.
But it’s worth noting atproto designers come partially from P2P lineage. Some worked on Scuttlebutt, IPFS, and others.
Technical problems give way to philosophical differences but the over-arching problem is that the people behind ATProto really want to make a social media ecosystem that attracts lots of average people who will refuse to understand that the solution you're giving them can't do things Twitter could do back before Musk bought it. People get angry enough at Bluesky not having an edit button, and it's at least possible to talk about how editing can be abused.
Both Blue Sky and Mastodon are that, if you squint.
(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)
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.
From my perspective, I care about the centralization/decentralization aspect a lot, and if I'm coming into the discussion with a much better understanding of the Mastodon side then _of course_ I'm going to ask about the instances--that's the vocabulary I'm going to use to try to probe for flaws and gaps. It's not necessarily that it's the instances specifically I care about, or that I'm somehow technically misguided.
What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.
I see! That's a huge topic by itself since you're raising a lot of questions. Maybe this could be a different article. My aim with this one was just to clarify the network topology because it is a prerequisite to having the other discussion, and too often that prerequisite is not there.
If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.
I felt the same: when folks ask this question they might not be using the correct terminology, but what they actually want to know is how many different PDSes (that's what you mean by "atproto hostings", right?) there are in a typical feed.
I appreciate that a lot! The article has a deliberate and explicit scope, and covers it well.
I'm hoping that perhaps my personal perspective shades why "instances" comes up, or why the reaction on HN seems to include the wider scope than the article itself covers.
Thanks for the fair response, I agree you're being cheeky. Sorry, I'm being lazy not searching here, but have you written anything on if instances of something is a good measure of decentralisation? (FWIW, I feel independently owned/managed instances in the traditional non-mastodon-definition seems like an okay measure of decentralisation.)
I completely agree with the point in your link that relays are different to instances - I love architectures involving dumb-relay or zero-trust type nodes. But I think Relays should still be mentioned in your post, since they're probably the main architectural element which protect PDS instances from the scale issues heavily federated AP instances might face, right? (I only have a high level understanding of ATProto and very little experience with AP, happy to be told I just need to learn more for this to make sense.)
It's a comparison they are directly inviting, by constantly claiming it's decentralized. And then its defenders get upset when people rightfully point out that there is only a single instance, because that single instance going down takes the whole thing down. Like in Google Reader.
if mastodon.social goes down, people would rightfully say that mastodon.social went down even though it's open source and anyone could run their own.
>"But where are all the Bluesky instances?"
I agree that it doesn't mean "atproto went down", and I don't mean to imply that. but "bluesky went down" is completely accurate, and bluesky is the one claiming to be decentralized due to using atproto. there are no other instances in bluesky's network, only partial ones (blacksky, last I heard they were still working on a major piece?), hence the "no it's not" responses. and that's also how they're directly encouraging people conflating the two.
I’m speaking about the hypothetical situation where an app is blown from the face of the earth, not temporarily goes down. I thought that’s what the parent discussion was about. I’m not sure what we’re discussing now.
All I’m saying is that if a developer forever takes down some atproto app, another developer can put up a new app that shows the old app’s data because the data is actually inside the users’ repositories. This is similar to how if Microsoft ever discontinued Word, you could still open Word documents in Google Docs. Does that make sense?
Re: Blacksky, they do fully run on their own infra now. So it doesn’t depend on Bluesky’s database.
it's somewhat similar, yeah. minus the part where bluesky itself is by far the majority host of people's data. that puts it more in the realm of "Office 365 Online + OneDrive storage" than "Word" - a lot of people will lose a lot of data, though something resembling it can be started up again. and people with backups (their own PDS) will just move to OpenOffice for a bit.
Blacksky finishing their full forking does finally give them a much stronger leg to stand on for "bluesky is decentralized", though.
PDSes are great and I really wish Mastodon would support something similar. Mastodon's lack of account portability / data ownership / lightweight hosting is a massive issue.
I found the distinction and comparison about Mastodon and ATProto are necessary. The fediverse model is easier to understand given existing social networks. ATProto is a novel concept that give users data sovereign and also the scalability of the centralized social networks.
I agree, a comparison and distinction is helpful, maybe even necessary. But I felt the author's bias came across a bit too strong in places and was a little distracting. Still interesting stuff though!
I think the analogy presented here is broken. RSS doesn't depend on Google Reader at all. Even at its prime, RSS depended less on Google Reader than email depends on Gmail now. In ATProto, AppViews heavily depends on Relays to be useful, and Relays are quite expensive to run. Also, the yellow circles which represent blogs in the RSS illustration are really not of the same nature as the same circles which represent posts on Facebook. Blogs are self-sufficient, for example.
I'm not saying ATProto is bad at all, but I feel like this blog post adds more confusion than it clarifies anything.
While relays are among the more intensive parts of AT Protocol infrastructure, their cost of operation is still something most people can afford: approximately $30/mo now. What is truly expensive and difficult is something that will be immutably so regardless of how centralized or decentralized you are: moderation.
Relays are actually quite cheap now! They used to be a bit more expensive when they archived all the traffic, but in sync 1.1 that was dropped and they can be run on $20/mo VMs pretty trivially now
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.
You can scale down as much as you want. You don't need to run full relay if you want to follow only a dozen of accounts. I bet you can run something like that on a raspberry pi or something similar. You will not get the search over all of the network, but that's something you don't get with your personal mastodon instances either.
If it quacks like a duck... An account has a single Personal Data Server (PDS), right? The DID links to a PDS which is the canonical data feed for a user, and where a user's writes go. Data can be replicated but the PDS is treated as canonical. That's much closer to client/server architecture than distributed architecture. There's no P2P database. There's no writes into a DHT or peers. You write to your PDS, then those writes are optionally mirrored. Also discovery happens via DNS, so you don't even ask peers for data. You connect to a relay not as a peer but as a client asking a server for a copy of data that's canonically hosted by the PDS. I don't think it's a stretch to call the PDS an instance and the relay a mirror.
Yeah sure that’s a fine way to phrase it. It’s not what most people who talk about Mastodon mean by “instance”. In Mastodon, “instance” is a coupled and inseparable data hosting + app + community + moderation pairing.
From a user’s perspective: To use Bluesky I need to create an account, and to create an account I need to choose the server where that account is hosted. Once I have an account I can follow any account even if hosted w/ someone else. That’s the same UX as Mastadon (leaving aside that moving PDS might be easier in ATProto than ActivityPub).
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. If your blog has comments, you can moderate them, for better or worse.
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.
> Web pages aren’t digitally signed, aren’t necessarily indexed by search engines
Neither of these prevent scraping, and the lack of the first one actually makes it worse because every scraper has to go to the original server and bog it down instead of getting it from anyone with a copy of the data that they can verify using the signature.
> there are ways to block bots with things like captchas
These don't work if you have anything resembling high value content, because AI can solve them now or do the same proof of work as a real user when all they need is to get a few hundred articles once. If they want it enough they can also pay someone in a low income country to download them manually. Fundamentally if you post something that any human can access then someone can copy it. Public is public.
And if the content is the equivalent of blog comment posts, they can probably still get it, but in that case why even care if they do? Notice that this is the same thing that happens on the centralized services, e.g. Facebook uses your Facebook posts to train AI.
Honestly that’s just as much because atproto is a raw data protocol. Putting an http frontend on an atproto account is something we encourage and a lot of folks do. I do that on pfrazee.com for instance, and my leaflet blogposts (which are canonically on atproto) render on my blog.
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 think that’s a part of it but doesn’t state it fully.
AT doesn’t just give consistency, but a shared data model across apps. So apps can reference and render content from other apps. It’s really kind of like a web of typed JSON. Different apps are lenses through which you can see the same network. Anyone can build new experiences on top of old data. There’s nothing remotely equivalent in AP.
AP couples data to apps. In AT, it’s more like there’s one global database with entire world’s data that every app can query.
I don’t understand why the discussion always bumps into Relays. Running a Relay if you want to is cheap-ish ($30/mo) these days. There’s multiple existing ones (Bluesky or community) you can use for free. And many apps don’t use one at all and rely on community indexes like Constellation (https://constellation.microcosm.blue/). Some don’t even run their own server or database.
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".
If you’re asking about moderation, it works similarly as you’d expect it to work in a everything-RSS world.
At the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things.
At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content.
There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices.
> Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows).
This is the part I would be looking for, in an article talking about "there are no instances". Is there a standard protocol for this, so that anyone can spin up a shared moderation service that people can subscribe to if they're aligned with it, and be able to plug that into any standard app built on the protocol (not just Bluesky-the-company's app)? Or is this something specific to Bluesky-the-company?
If this is a standardized part of the protocol, then that answers the question of "how does ATProto solve the same problems defederation solves".
There are several other things I can think of in the category of "how do you solve the problems that ActivityPub uses instances to solve", but they're things I've already asked in other parts of this thread, namely "how do you make the parts of the system not shown in the tidy hosts->apps M:N graph decentralized, too".
Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
> it fails to answer "so how does atproto solve the problems that defederation solves?".
The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances.
It's an architectural choice that has the long-term effect of cementing an oligopoly.
Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default.
Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.
It doesn't solve those problems, except in an alternative universe where there are a very large number of appviews capable of consuming the entire firehose and you can freely choose between them and cheaply run your own. ATProto is like RSS in a universe where you can only read RSS through Google Reader (or a clone of Google Reader running on the same scale).
I’m running an atproto app and it’s perfectly capable of ingesting the entire firehouse as it comes in. It costs me maybe $10/mo and mostly because I haven’t fixed some memory leaks.
Of course, few of records that come through are relevant to my app so I don’t store them.
If I wanted to store gigabytes of records (like Bluesky) for millions of users forever then yes it would be more expensive. Which would be the case with any tech! What are you comparing it to? How is this a downside of atproto?
Mastodon instances aren’t a valid comparison point because by definition they’re small-world. They don’t serve millions of users.
If your point is that you want small-world atproto, that’s absolutely possible. Take the Bluesky server codebase and make it so that it ignores incoming content beyond some criteria (like “follows of server member list”). You can recreate Mastodon experience on atproto, it just hasn’t been very interesting to anyone so far AFAIK.
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.
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:
One thing I like about the ATProto is the stable identity, I could change the hosting as the author did recently and the other users see no difference.
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.
The cost of ATProto is only high if your AppView has a goal of "every user should be able to see and access every post and interaction indefinitely". If one limits the scope of what users see on their AppView to, say, a similar scope as what popular ActivityPub applications do (only posts and interactions from users that use that instance, and people that they interact with / follow are available / retained), it becomes not that expensive at all.
The difference is that it's easy to scale ATProto AppViews up beyond the reach of their users. It can scale down though. It is not easy to scale ActivityPub instances up beyond the scope of the people who use it, and it would probably be way more expensive if you tried.
I wouldn't say other components are expensive. Common ones are:
- Relay as an optimization. That's cheap-ish ($30/mo) or free-ish if you pool with others.
- Your own app server. That's on par with normal web apps as long as you can keep a socket open. What's expensive is if the app you're making is a fully capable copy of Bluesky itself with gigabytes of existing posts — but is that the app you're making? The economics here are identical to normal web app stuff.
> What's expensive is if the app you're making is a fully capable copy of Bluesky itself with gigabytes of existing posts
This is the implicit idea in my comment when I said it's expensive. If Bluesky banned me and I could not find another AppView with comparable reach and audience, I lose, the ban is effective.
Another problem is ATProto users don't usually associate then with an AppView the same way Mastodon users associate with the instance, it's hard to raise fund to sustain the infrastructure cost.
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.
I think email is a pretty poor example of decentralization in the modern internet. I pay a company to not have to worry about hosting my own and I've still had emails blackholed by the massive providers for unknown reasons I can only assume are some combination of the custom domain* and the provider. I went back to using Gmail on my resume and for applications after nearly missing out on an interview because of it.
- 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?
Well, I think you also need to consider what PLC is. It’s an open source implementation of an open source spec. The implementation holds zero private state and exposes a verifiable log of operations for audit. There’s ongoing work on mirrors and replicas. Also, its output itself is cryptographically self-verifying.
I get that it’s not ideal but I think it’s worth keeping in mind that there’s not much you can mess up with it other than refusing to update requests. The threat model is very limited and it would immediately be obvious that this is happening, killing the credibility.
Based on my understanding, PLC is centralized primarily because there needs to be a global, authoritative source of truth for the current state of a given plc. You could in theory namespace a plc to a particular directory instance with a backwards reference or something, but I don't think it buys you anything when in theory you can just choose to trust a different PLC directory at the read/application layer if you really need.
At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.
That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.
I’d also call out that activitypub has the same threat model in the form of ICANN, as it’s also heavily dependent on DNS for identity. I believe these are reasonable trades to make; realistically the alternative is to use a blockchain, which few people are keen to do.
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?
I think the centralization on mastodon.social is a bit over estimated. According to fedidb.com there are over 1.1M active users in the fediverse. Of these mastodon.social has about 273k. That means mastodon.social has about 1/4 of the active users. The rest are scattered over nearly 43k servers. So I'd say the fediverse is pretty decentralized. That would make it pretty resilient.
On fedi there are several distinct pockets apart from the mastodon crowd which although don't dominate in raw headcount have their own flavour and unique view of the network (in 2nd place is "dark fedi", which has more shitposters, hackers and free speech adjacents; there's also a contingent of Japanese users mostly on Misskey instances). What I get out of AT is that this wouldn't really happen, since the content distribution would dominate your view with Bluesky posts regardless of your relationship with the rest of the network.
In AT you also get communities, in the same way that twitter had weird twitter, black twitter, and so on. But because you, by design, don't really see what PDS people use, it's more fluid.
I personally think that this actually leads to healthier communities but that may be a matter of taste!
Yeah, I mean a big reason why Fedi is segmented the way it is, is because the Mastodon crowd has a lot of merited and unmerited prejudices against the other parts of the network, and put a lot of effort into splitting it with centralized blocklists. The W3C working group that works with the AP spec (which refuses to cooperate with credible people representative of projects like Pleroma) is now looking to adopt a centralized moderation model similar to Bluesky's. It's one of the issues with the instance model, even though users have the tools to shape their own view of the network, to not have to see things they don't like, instance admins still get to dictate who they're allowed to talk to and what they see. I don't think that's right, even if the reasons are justifiable.
The guy who runs FSE (one of dark fedi's more notable instances) has written a lot of good blog posts on his side of the technical and social details, his one about running FediList is a good picture of the type of one-sided politics involved (and, if you're into the technical stuff, is rich with that too): https://blog.freespeechextremist.com/blog/about-fedilist.htm...
re: censorship & moderation, the folks @ BlackSky have been active in building out an alternative moderation structure (alongside running PDSes & AppViews).
I feel like the charts could be clearer if they showed the primary user experience difference between RSS and AT/AP, which is how do the arrows flow for Bob's response to Cat's post. I understand it fairly well for AP, I don't think I actually get it for AT.
TLDR: at the hosting layer, it's like <a href> links, but in JSON. Links can refer to other person's repo (even if it's hosted somewhere else). And then apps index everything, so they can present a coherent aggregated view (like a post thread).
Hah, well that's my bad for not reading articles I've saved, after reading those I remembered Puzzmo mentioned this recently and they, of course, got inspired by that second article: https://blog.puzzmo.com/posts/2026/03/02/atproto/
All the nitpicking in this thread is missing the forest for the trees. You know what’s really bad for decentralization? The rest of the world living on fully centralized apps mostly belonging to one of 3 billionaires with no public protocol in sight.
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.
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.
Exactly this, people seem to confuse decentralization with federation. The Blockchain is decentralized, the fediverse is federated, big difference. I think it's because what we actually want and need right now (with western regimes dialing up censorship and repression to eleven) is decentralized social media, but that doesn't exist yet unfortunately.
Blogs are also hosted on instances, similar to the Mastodon diagram. The only difference is that the reader aggregator doesn't necessarily have to run on the blog host instance.
When the first paragraph starts out by insulting people for not using the exact jargon you want them to, it really doesn’t make me want to read the rest.
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.
I mean, this literally already happened (a person was banned, and Blacksky reversed that ban on their app server). So their account only works when seen thorough the Blacksky app. What is a better solution you’d like to see? I think it’s reasonable that there’s a market between these and if there’s enough demand, another app server can become popular. I don’t think it’s reasonable to expect that the apps shouldn’t be in control of their own moderation.
> I mean, this literally already happened (a person was banned, and Blacksky reversed that ban on their app server).
Blacksky is literally the only such example of alternative infrastructure that I know of, and obviously, it will not be applicable to the vast majority of people. Given the rising cost of hosting combined with the fact that the compute needs of running appviews and relays should theoretically only go up, I have a strong feeling that there will not be a lot more of them, either. It's already bigger than ActivityPub I believe and we're in the very low single digits at best.
Meanwhile, if we really did get a lot of these instances, then it really begs the question what the actual benefit of Bluesky's ATProto architecture is: if someone is banned on Bluesky and not Blacksky... won't users see a totally different view of the world? Isn't that the same problem ActivityPub sees? How does this really differ from defederation in practice?
> What is a better solution you’d like to see? I think it’s reasonable that there’s a market between these and if there’s enough demand, another app server can become popular.
If I knew how to fix this, I would probably be trying to help rather than criticizing ATProto. I don't think it can be fixed, so I don't have any suggestions.
> I don’t think it’s reasonable to expect that the apps shouldn’t be in control of their own moderation.
It kind of sounds like you're admitting that there is no real difference from a user standpoint with browsing to twitter.com vs bsky.app that have anything to do with decentralization.
I know I'm not going to win a popularity contest here, you don't even have to bother responding, honestly. But just being honest, I know you're a pretty intelligent person and the work you have done has benefited my life as a developer. I have a feeling deep down you also realize there is an inherent contradiction with Bluesky and ATProto's marketing pitch. I wish you would be honest about it.
The Fediverse has value specifically because of its downsides. A version of decentralized social media without those downsides inherently picks up almost all of the disadvantages of centralized social media. To me it seems apparent that all you can do is move the sliders around a bit, and Bluesky appears to net a very tiny percent of benefit from decentralization while bearing immense cost for it.
> It kind of sounds like you're admitting that there is no real difference from a user standpoint with browsing to twitter.com vs bsky.app that have anything to do with decentralization.
Bluesky users can interact with Blacksky users and vice versa unless Bluesky has applied moderation to the Blacksky user, because they are decentralized via ATproto. ~Twitter~ X users cannot interact with users on any other application, because X is not decentralized.
> Bluesky users can interact with Blacksky users and vice versa unless Bluesky has applied moderation to the Blacksky user, because they are decentralized via ATproto.
Yes and I find it rather egregious that you can pay (a lot) to self-host a full stack then still be locked out of the majority of the audience of an entire "decentralized" platform by a single centralized entity.
For all of the problems with ActivityPub defederation, at least with ActivityPub you have:
- Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.
- The option to feasibly self-host your own instance that is completely independent. You can be blocked by the major instances still, so they still have the ability to moderate just the same. However, as far as I know no AP server has more than half the active users of the whole network, which is a much more robust split.
It's true that Bluesky architecture enables something like Blacksky to exist. But if there were just two independent ActivityPub hosts and one of them was many multiples the size of the other the protocol would've been declared a massive failure for good reason.
And as far as I know the Fediverse mobile apps and clients are agnostic to your instance, so the apps don't have any influence over what you're able to see. Isn't this what is expected from something that is decentralized?
Yep. Effectively, there are a low single digit number of ATProto "instances" - they just pull posts from a more decentralized data layer than Fedi instances.
I don't think I agree. There's nothing intrinsic about the PLC and PDS servers that tie an AT account tighter to your own identity, than an account on an ActivityPub instance in my opinion.
Correct me if I'm wrong, but I'm guessing by plausible deniability you mean that ActivityPub essentially forces you to shred your old account if you need to move instances? Apart from the fact that AT also doesn't impose a "one DID per human identity rule" (yet?), allowing you to move between AT identities and PDS instances as much as you like, there's no hindrance to anyone that really wants to track your account movement between AP accounts of they even slightly want to do so. By default ActivityPub leaves a little entry on your old account saying "the person behind this account move to instance so-and-so", which is what allows you to migrate your followers with you in the first place, but that leaves just as much of a trail than your DID moving from PDS to PDS, and if you want that message to not be there, giving you said plausible deniability, you're just back to creating fresh accounts every time, just like AT.
I mean I think it's hard to say that one platform is better than the other in that regard because the platforms are really really similar to each other from a broad perspective. If you take ActivityPub, break up the concept of an instance into one part that keeps the data and one part that shows the data, scrap the usernames in favor of random IDs, and stick a few more services in between, you've already arrived at the AT protocol, the oversimplification aside.
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?
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'm pretty sure this comment is not written by AI, but those last few sentences really really made me think it is. It's a little sad that this type of antithesis now always has this AI-written connotation to it.
"That's not you cheating. It's you looking for emotional fulfillment. And frankly? That's courage."
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.
I haven't used Mastodon, but my experience with Lemmy was a lot of petty fighting about who should be defederated. The OP's reference to warring fiefdoms was very spot-on for that scene. I imagine it's a huge turn off to casual, well-adjusted people exploring the space. But I wouldn't know.
There's, of course, another sort of grossness to corporate moderation from above, but at least with ATProto you can take your identity and content to another AppView, if it wasn't shown there already. AFAIK, any fediverse migration tooling requires a cooperative host server you haven't already been banned from.
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.
You're treating Mastodon as the protocol here, and sure it's a combined frontend/backend, and it is the most used one, but its just one implementation of the AP protocol. You can plug your favourite AP app/frontend into any Mastodon instance.
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.
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.
This article is deeply, deeply misleading, in that it leaves out relays and appviews in all of its diagrams of the ATProto network. Like, are ATProto identities namespaced by instance/home-server like Mastodon or Matrix identities? No. Does who you are able to follow dependent on the appview you connect to? Yes. Are you able to run your own appview? Probably not (this answer has been upgraded from "No" in only the last few months).
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.
Of course depends on the context, but in a lot of discussions about ATProto, ActivityPub, Mastodon and nearby areas, people talk about "instances" as in "ActivityPub instances that host my data and my profile uses its URL as a 'name'". The blog post is specifically for that context I think.
It's less about trying to hide around the issue, and more reframing how you see the concepts, as people start to associate words with concepts and structures. So when people talk about "decentralized social media", lots of people think about ActivityPub, which typically (always?) has a kind of federated architecture, and the instance is one of those nodes in the network. When these people see ATProto, instinctively (and perhaps rightly so) they literally ask "But why is there only one Bluesky instance that people join?" as those concepts map close to what they know.
Overall I think the post is a good and useful addition to the discourse, with perhaps not a completely novel perspective, but posted publicly for future reference when this inevitably gets asks again sometime in the future, specifically for the people who have these previous associations already formed in their head.
Swarms of content.
Cryptographic identities and content signing/attribution.
Cryptographic hashes for content uniqueness/immutability.
Immutability in general.
Ephemerality (content lives as long as some node cares to retain it, otherwise it gets forgotten).
Concrete but extensible ontology for core concepts.
You don't need login. You don't need to agree on a common platform. 3rd party tools and extensions can filter content, provide trust graphs, interest graphs, etc.
You can just slurp up and score whatever might interest you. Your agent or algorithm might do pre-filtering against your preferred heuristics to downsample to relevancy.
You could write any client for this in any shape or form. Completely different look and feel for different people and interests / focuses.
Atproto is an attempt to engage with the problem space in a way that hits the baseline UX of Web 2.0 apps.
But it’s worth noting atproto designers come partially from P2P lineage. Some worked on Scuttlebutt, IPFS, and others.
And maybe that's a good thing.
(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)
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.
What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.
If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.
I'm hoping that perhaps my personal perspective shades why "instances" comes up, or why the reaction on HN seems to include the wider scope than the article itself covers.
I completely agree with the point in your link that relays are different to instances - I love architectures involving dumb-relay or zero-trust type nodes. But I think Relays should still be mentioned in your post, since they're probably the main architectural element which protect PDS instances from the scale issues heavily federated AP instances might face, right? (I only have a high level understanding of ATProto and very little experience with AP, happy to be told I just need to learn more for this to make sense.)
Even if it’s not open source, anyone who wants to write the code can still get it back up with all public data intact.
I think it’s a substantial difference with “takes the whole thing down”. Can we acknowledge that?
>"But where are all the Bluesky instances?"
I agree that it doesn't mean "atproto went down", and I don't mean to imply that. but "bluesky went down" is completely accurate, and bluesky is the one claiming to be decentralized due to using atproto. there are no other instances in bluesky's network, only partial ones (blacksky, last I heard they were still working on a major piece?), hence the "no it's not" responses. and that's also how they're directly encouraging people conflating the two.
All I’m saying is that if a developer forever takes down some atproto app, another developer can put up a new app that shows the old app’s data because the data is actually inside the users’ repositories. This is similar to how if Microsoft ever discontinued Word, you could still open Word documents in Google Docs. Does that make sense?
Re: Blacksky, they do fully run on their own infra now. So it doesn’t depend on Bluesky’s database.
Blacksky finishing their full forking does finally give them a much stronger leg to stand on for "bluesky is decentralized", though.
PDSes are great and I really wish Mastodon would support something similar. Mastodon's lack of account portability / data ownership / lightweight hosting is a massive issue.
Instead of decrees over the "filioque" we get blog posts about the definition of "federation" where both parties talk past each other.
I'm not saying ATProto is bad at all, but I feel like this blog post adds more confusion than it clarifies anything.
While relays are among the more intensive parts of AT Protocol infrastructure, their cost of operation is still something most people can afford: approximately $30/mo now. What is truly expensive and difficult is something that will be immutably so regardless of how centralized or decentralized you are: moderation.
The author of this piece wrote about this common misconception about relays 9 months ago: https://news.ycombinator.com/item?id=45077291#45078223
Your definition of "most people" must be very different than the literal meaning.
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.
How does this differ from scrapers hitting the blog directly?
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.
Neither of these prevent scraping, and the lack of the first one actually makes it worse because every scraper has to go to the original server and bog it down instead of getting it from anyone with a copy of the data that they can verify using the signature.
> there are ways to block bots with things like captchas
These don't work if you have anything resembling high value content, because AI can solve them now or do the same proof of work as a real user when all they need is to get a few hundred articles once. If they want it enough they can also pay someone in a low income country to download them manually. Fundamentally if you post something that any human can access then someone can copy it. Public is public.
And if the content is the equivalent of blog comment posts, they can probably still get it, but in that case why even care if they do? Notice that this is the same thing that happens on the centralized services, e.g. Facebook uses your Facebook posts to train AI.
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.
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.
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.
AT doesn’t just give consistency, but a shared data model across apps. So apps can reference and render content from other apps. It’s really kind of like a web of typed JSON. Different apps are lenses through which you can see the same network. Anyone can build new experiences on top of old data. There’s nothing remotely equivalent in AP.
AP couples data to apps. In AT, it’s more like there’s one global database with entire world’s data that every app can query.
I don’t understand why the discussion always bumps into Relays. Running a Relay if you want to is cheap-ish ($30/mo) these days. There’s multiple existing ones (Bluesky or community) you can use for free. And many apps don’t use one at all and rely on community indexes like Constellation (https://constellation.microcosm.blue/). Some don’t even run their own server or database.
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 the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things.
At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content.
There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices.
Does this help clarify it?
This is the part I would be looking for, in an article talking about "there are no instances". Is there a standard protocol for this, so that anyone can spin up a shared moderation service that people can subscribe to if they're aligned with it, and be able to plug that into any standard app built on the protocol (not just Bluesky-the-company's app)? Or is this something specific to Bluesky-the-company?
If this is a standardized part of the protocol, then that answers the question of "how does ATProto solve the same problems defederation solves".
There are several other things I can think of in the category of "how do you solve the problems that ActivityPub uses instances to solve", but they're things I've already asked in other parts of this thread, namely "how do you make the parts of the system not shown in the tidy hosts->apps M:N graph decentralized, too".
Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances.
It's an architectural choice that has the long-term effect of cementing an oligopoly.
Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default.
Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.
I’m running an atproto app and it’s perfectly capable of ingesting the entire firehouse as it comes in. It costs me maybe $10/mo and mostly because I haven’t fixed some memory leaks.
Of course, few of records that come through are relevant to my app so I don’t store them.
If I wanted to store gigabytes of records (like Bluesky) for millions of users forever then yes it would be more expensive. Which would be the case with any tech! What are you comparing it to? How is this a downside of atproto?
Mastodon instances aren’t a valid comparison point because by definition they’re small-world. They don’t serve millions of users.
If your point is that you want small-world atproto, that’s absolutely possible. Take the Bluesky server codebase and make it so that it ignores incoming content beyond some criteria (like “follows of server member list”). You can recreate Mastodon experience on atproto, it just hasn’t been very interesting to anyone so far AFAIK.
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.
So in this analogy, anyone would be able to bring Google Reader back to life or compete while using that same graph.
That’s actually how http://leaflet.pub works now if you’re curious.
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...
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.
The difference is that it's easy to scale ATProto AppViews up beyond the reach of their users. It can scale down though. It is not easy to scale ActivityPub instances up beyond the scope of the people who use it, and it would probably be way more expensive if you tried.
- Relay as an optimization. That's cheap-ish ($30/mo) or free-ish if you pool with others.
- Your own app server. That's on par with normal web apps as long as you can keep a socket open. What's expensive is if the app you're making is a fully capable copy of Bluesky itself with gigabytes of existing posts — but is that the app you're making? The economics here are identical to normal web app stuff.
This is the implicit idea in my comment when I said it's expensive. If Bluesky banned me and I could not find another AppView with comparable reach and audience, I lose, the ban is effective.
Another problem is ATProto users don't usually associate then with an AppView the same way Mastodon users associate with the instance, it's hard to raise fund to sustain the infrastructure cost.
It seems to be the nexus of federation + https://signal.org/blog/the-ecosystem-is-moving/
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."
*: Not an .xyz, has proper SPF and DKIM records
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.
- 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.
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?
I get that it’s not ideal but I think it’s worth keeping in mind that there’s not much you can mess up with it other than refusing to update requests. The threat model is very limited and it would immediately be obvious that this is happening, killing the credibility.
At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.
That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.
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.
I personally think that this actually leads to healthier communities but that may be a matter of taste!
The guy who runs FSE (one of dark fedi's more notable instances) has written a lot of good blog posts on his side of the technical and social details, his one about running FediList is a good picture of the type of one-sided politics involved (and, if you're into the technical stuff, is rich with that too): https://blog.freespeechextremist.com/blog/about-fedilist.htm...
Also here: https://overreacted.io/a-social-filesystem/#links
TLDR: at the hosting layer, it's like <a href> links, but in JSON. Links can refer to other person's repo (even if it's hosted somewhere else). And then apps index everything, so they can present a coherent aggregated view (like a post thread).
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.
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?
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.
Blacksky is literally the only such example of alternative infrastructure that I know of, and obviously, it will not be applicable to the vast majority of people. Given the rising cost of hosting combined with the fact that the compute needs of running appviews and relays should theoretically only go up, I have a strong feeling that there will not be a lot more of them, either. It's already bigger than ActivityPub I believe and we're in the very low single digits at best.
Meanwhile, if we really did get a lot of these instances, then it really begs the question what the actual benefit of Bluesky's ATProto architecture is: if someone is banned on Bluesky and not Blacksky... won't users see a totally different view of the world? Isn't that the same problem ActivityPub sees? How does this really differ from defederation in practice?
> What is a better solution you’d like to see? I think it’s reasonable that there’s a market between these and if there’s enough demand, another app server can become popular.
If I knew how to fix this, I would probably be trying to help rather than criticizing ATProto. I don't think it can be fixed, so I don't have any suggestions.
> I don’t think it’s reasonable to expect that the apps shouldn’t be in control of their own moderation.
It kind of sounds like you're admitting that there is no real difference from a user standpoint with browsing to twitter.com vs bsky.app that have anything to do with decentralization.
I know I'm not going to win a popularity contest here, you don't even have to bother responding, honestly. But just being honest, I know you're a pretty intelligent person and the work you have done has benefited my life as a developer. I have a feeling deep down you also realize there is an inherent contradiction with Bluesky and ATProto's marketing pitch. I wish you would be honest about it.
The Fediverse has value specifically because of its downsides. A version of decentralized social media without those downsides inherently picks up almost all of the disadvantages of centralized social media. To me it seems apparent that all you can do is move the sliders around a bit, and Bluesky appears to net a very tiny percent of benefit from decentralization while bearing immense cost for it.
Bluesky users can interact with Blacksky users and vice versa unless Bluesky has applied moderation to the Blacksky user, because they are decentralized via ATproto. ~Twitter~ X users cannot interact with users on any other application, because X is not decentralized.
Yes and I find it rather egregious that you can pay (a lot) to self-host a full stack then still be locked out of the majority of the audience of an entire "decentralized" platform by a single centralized entity.
For all of the problems with ActivityPub defederation, at least with ActivityPub you have:
- Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.
- The option to feasibly self-host your own instance that is completely independent. You can be blocked by the major instances still, so they still have the ability to moderate just the same. However, as far as I know no AP server has more than half the active users of the whole network, which is a much more robust split.
It's true that Bluesky architecture enables something like Blacksky to exist. But if there were just two independent ActivityPub hosts and one of them was many multiples the size of the other the protocol would've been declared a massive failure for good reason.
And as far as I know the Fediverse mobile apps and clients are agnostic to your instance, so the apps don't have any influence over what you're able to see. Isn't this what is expected from something that is 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.
Correct me if I'm wrong, but I'm guessing by plausible deniability you mean that ActivityPub essentially forces you to shred your old account if you need to move instances? Apart from the fact that AT also doesn't impose a "one DID per human identity rule" (yet?), allowing you to move between AT identities and PDS instances as much as you like, there's no hindrance to anyone that really wants to track your account movement between AP accounts of they even slightly want to do so. By default ActivityPub leaves a little entry on your old account saying "the person behind this account move to instance so-and-so", which is what allows you to migrate your followers with you in the first place, but that leaves just as much of a trail than your DID moving from PDS to PDS, and if you want that message to not be there, giving you said plausible deniability, you're just back to creating fresh accounts every time, just like AT.
I mean I think it's hard to say that one platform is better than the other in that regard because the platforms are really really similar to each other from a broad perspective. If you take ActivityPub, break up the concept of an instance into one part that keeps the data and one part that shows the data, scrap the usernames in favor of random IDs, and stick a few more services in between, you've already arrived at the AT protocol, the oversimplification aside.
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.
"That's not you cheating. It's you looking for emotional fulfillment. And frankly? That's courage."
There's, of course, another sort of grossness to corporate moderation from above, but at least with ATProto you can take your identity and content to another AppView, if it wasn't shown there already. AFAIK, any fediverse migration tooling requires a cooperative host server you haven't already been banned from.
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.
The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.
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.