> Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly.
I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto specifically at the expense of ActivityPub (and RSS, a bit). I think you lower yourself by doing this:
1. it forces you to omit and contort the interesting technical truths about ATProto and Activitypub, like Relays and their pros/cons for ATProto and account migrations and pros/cons for ActivityPub
2. it creates unnecessary conflict and criticism and seems unnecessarily divisive for 2 platforms solving problems in such a similar space
It's also just seems a bit silly: why would you assume that when someone asks "where are the instances?" they're not using the common mainstream use of the word "instances", like, servers, or running software, or VMs, or containers?
Sorry if this is overly harsh or I've misunderstood, but it gives me a strong vibe that it was motivated by disdain and frustration towards ActivityPub and ActivityPub users rather than wanting to legitimately inform the world about ActivityPub.
I did enjoy the diagrams and the explainers though! I just felt like the subtle digs and pops at activitypub were an unnecessary distraction.
I'm being a bit cheeky in the article's tone but I am fairly confident from discussions in the past that "But where are Bluesky instances?" is a common question which usually demonstrates a misunderstanding of the architecture where "having instances of an app" is seen as a measure of decentralization.
My article was an attempt to dig at this specific misunderstanding by comparing it to "But where are Google Reader instances?" which I think illustrates its absurdity. I genuinely do think that the two pictures I provide close to the end clear this up in a way a lot of early atproto/ActivityPub discussions completely gloss over.
Re: Relays, I wrote here on why I didn't include them: https://news.ycombinator.com/item?id=48600963. They're kind of incidental perf optimizations rather than essential to the model. In the post, I wanted to focus on the model.
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 could see "Bluesky AppView" has similar semantic as Mastodon instance: network, moderation...
The difference is on ATProto, when I get banned, people must switch to another "AppView instance" (could be reusing the same Bluesky AppView stack) to interact with me. I summary, my data is not lock in, but my audience could be.
On the other aspect, Bluesky AppView is only a small part (a microblogging network) of the bigger Atmosphere where we can create different AppViews for different use cases, e.g. publishing (leaflet.pub), code repository (tangled.org). Users can use the same handle and PDS for these AppViews.
Yeah I wanted to say that. From a user's point of view, it sounds like the AppView is the instance. If you disagree with the moderation, you can move to a different AppView (that may use different relays) but keep your PDS.
Whereas with Mastodon your PDS is your AppView, so if you leave the AppView you lose your PDS (and have to somehow export it).
Yeah, I have the same understanding. On Mastodon, an instance is an all on one package. On Bluesky, each component can be deployed separately. The nuance is Bluesky PBC own the Bluesky (iOS, Android, Web) apps, the AppView and the default PDS hosting, I could say it's centralized by default and decentralized at will.
I'm not sure that's totally right, though, because I (using the entirely default bsky stack) can and do regularly interact with people who are using different PDS and AppView's (like, I can interact with Eurosky and blacksky accounts).
I think the thing that is centralized by default is the bsky moderation layer.
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'm one of those "is it decentralized yet" people and to me the real concern is the AppView since I assume that's where censorship would be applied if it ever happens. People keep telling me about PDSes but I don't care about controlling my PDS if other people can't see my posts.
I wouldn’t say censorship alone is the primary motivation here so I’m a bit wary when people bring it up. But the way to think about it is that your data being on PDS is the mechanism that creates a market opportunity for other apps that, among other things, differ in moderation strategies.
Concrete example: Bluesky banned a person, and Blacksky community disagreed with that ban. When Blacksky switched http://blacksky.community app to have its own complete stack (including its own database), that person’s posts became visible there (despite them being banned on Bluesky app) because they reversed that moderation decision. This was possible because the data for this person’s posts still lives on their PDS.
In general, the data being “pulled outside” products is what enables new products (or forks of products) to come onto the scene and immediately begin competing because they don’t have to solve the “cold start” problem. If you log in, all your stuff is “already there”. And it’s the same shared world so the community doesn’t get forked. You’re just looking at the same underlying data under a different lens, and products act like lenses rather than boxes.
This doesn’t mean that “censorship” can’t exist (every layer can ban you, as always) — but it means that every layer of the stack has opportunity for competition that isn’t possible with centralized platforms. In fact, arguably, it’s more flexible than a Mastodon instance because you can’t fork a Mastodon instance “with all its users” and offer a version that reverses some moderation decision. In atproto, you can.
> I don't care about controlling my PDS if other people can't see my posts.
Isn't that similar with Mastodon? Someone on an instance that does not federate with yours will not see your posts, and I guess someone on an instance that would censor you would not see your posts?
That someone would have to change instance if they disagree with the moderation, and doing so is more painful with ActivityPub than with ATProto, right?
Disclaimer: I have no skin in this game, I don't use social networks. Just interested technically :-).
It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance, or pick one that aligns with your views and interests, such that the bulk of moderation is handled for you in terms of which instances you federate with etc.
I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?
You can trivially host an appview for your atproto app on your own. I have a hobby atproto app, and I host an appview for it. I mean — an “appview” literally just means “a server with a database that ingests stuff from the network”. It’s not some mysterious thing or some concrete distribution. It just means you’re aggregating stuff into your database.
It’s just as cheap as hosting any webapp.
But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense.
That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records.
Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people).
To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that.
People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.
Say bluesky is applying content moderation techniques I disagree with.
What steps do I have to follow to get the majority of users to see my content?
Another example. Let's define decentralisation in terms of bus factor:
How many companies could go bust today before most users would notice?
> To make the comparison fair
Okay, so let's build that, then we can actually talk about building a decentralized network on atproto.
How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?
From what I understand, in bluesky the PDS does not know about replies to a post. So I'd need to scrape the entire network anyway, no matter what, even if I only store some of it.
And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?
> What steps do I have to follow to get the majority of users to see my content?
You can’t “get” the majority of the people to see anything, that’s not how anything works. Neither on centralized systems, nor on Mastodon, nor in real life.
On a centralized platform, if you get banned, there are no steps you can take. Your account is down — goodbye.
On a Mastodon instance, there are also no steps you can take. Your account is banned on the instance — your entire identity goes down with it.
On atproto, it depend on whether you’re banned at hosting or app level.
If you get banned at hosting level (usually something clearly illegal would trigger this), you’d have to find another hosting (assuming apps haven’t banned you too).
If you get banned at an app level, people will see you through different apps. You’re right that this presupposes that there are apps that (1) people use, that (2) haven’t banned you, (3) and that display the same type of content.
But, even if you’re looking from solely censorship resistance perspective, atproto at least enables competition in moderation space to happen. If enough people disagree with the lens, it is possible to build a an alternative lens over the network.
This isn’t theoretical — there was a situation like this where a person got banned at Bluesky app, but the Blacksky community wanted to reverse the decision. When Blacksky got an independent app database running, they overrode it. But yes, this does require investment and a subset of community being interested in alternative moderation / features / etc. You can’t “force” people to hear you but there’s a market for alternatives.
> How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?
The realtime part is trivial. You just filter the stream of everything as it comes in.
Backfill would either require you to index the network yourself or to rely on existing indexes. You could use Constellation (https://constellation.microcosm.blue/) to fill up threads (query by thread root ID), and you’d hit the user’s PDS to fill up their profile page.
You could actually see that in practice now at https://reddwarf.whey.party/ which my article links to. It’s a Bluesky client that doesn’t have a server at all (and doesn’t hit Bluesky API). It’s lazily getting stuff on the client purely from PDS’s and from Constellation. It’s a bit slower than an appview-backed experience but it works fine.
The difference between Bsky and Mastodon is that Bsky unbundles PDSes and App Views, while Mastodon does not.
Migrating to a different App View should be painless in theory (app views are not supposed to collect any state that is not saved in the PDS, not sure if Bsky does or not), and you can use multiple app views with one PDS. On Mastodon, you have to migrate both at the same time, and moving content across instances is not yet a fully solved problem.
The difference between the two is that Bluesky has a central audience with decentralized content, while Mastodon has a federated audience with federated content.
Blueksy holds all the power, while the users hold none, whereas with Mastodon has many separate communities, similar to the old-school BBSes, forums, IRC and teamspeak servers.
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.
And only a handful of those have open signups (13 with open signups have >50 users).
Many of them are actually ActivityPub instances with a PDS bridge, e.g., https://join.wafrn.net/
And most of the other open signup instances are also primarily designed as their own social network, just using AT proto as a compatibility layer, e.g., https://sprk.so/https://haruhwa.com/ (which is an invite-based, snapchat-style ephemeral social network), https://surf.social/, https://pckt.blog/ (a microblogging platform), aesthetic.computer (a collaborative programming/art platform)
That leaves only bluesky, blacksky, eurosky, selfhosted.social, self.surf and npmx.social.
Even during Facebook's heyday, the unsuccessful diaspora/friendica/gnu social/etc networks had more decentralization than that.
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.
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.
> blacksky, last I heard they were still working on a major piece?
While that was true, I don't think it's true anymore. I think blacksky is fully independent. Eurosky is currently in the spot you're describing (partially independent, but moving towards also being fully independent).
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.
They're funding Fig to create and run a "full network backup" solution. What Bluesky really needs to do is figure out a way to get users to own their own backup recover key, whether personally or through some third-party service.
I'm sorry, just to clarify: in your scenario where the app/company is suddenly vaporized from the face of the earth, if that happened to Bluesky right now it would effectively mean that >90% of content currently published using Atproto would be lost?
Realistically, I can't say "yes" because I'm sure there's plenty of copies of entire network by now. They would be out of date but would have all old records. So that could be maybe 70% that's already backed up. I guess they likely won't include images/blobs. There's an ongoing project to build an always-available full archive with this specific purpose (https://atproto.com/blog/introducing-hubble-a-public-mirror-...) so it is also an active area of work.
If we imagine that nobody has a full copy today or is unwilling to share it, the answer would technically be yes.
I'd still say that, for an app going down, the answer is "no" because "Bluesky app" and "Bluesky hosting" are like two separate services. The point I was making was that specifically "apps going down doesn't destroy data". (The distinction between "Bluesky app" and "Bluesky hosting" isn't completely contrived because I'd expect the cost of running the app to be many orders of magnitude higher than the cost of running hosting.)
But if you pick a hosting company, and users don't have backups, and nobody does mirroring, then yes, hosting disappearing would destroy data. As with literally any hosting.
Yeah I'm kinda waiting for this. I don't like to join bluesky because I want it more decentralised but I can't join blacksky because it's only for black people.
I'm kinda hoping someone sets up a rainbowsky or something for us in the LGBT community. Now that I would join.
Blacksky is now fully independent and does not have any reliance on Bluesky whatsoever.
In fact, in cases where Bluesky _did_ go down, Blacksky was still working fine (if a little slow due to the amount of Bluesky people on Blacksky), and people were able to make posts and everything.
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.)
In Mastodon/AP, different instances talk to each other which creates the scale problem you’re mentioning.
AT doesn’t have this kind of issue even without Relays. This is because PDS never talks to another PDS so there’s no quadratic growth of edges. PDS only talks to apps, and there’s limited amount of apps on the network. And end users hit apps which cache stuff, so apps tend to take the user traffic hit.
Relays are helpful more on the app side because you don’t want to teach each app to crawl PDS’s and subscribe to them.
I didn’t dive into Relays in the article because they’re kind of a “next obvious optimization” but not really inherent to the model. There are other models like apps hitting shared backlink caches (like Constellation). Relay isn’t fundamental in the way hosting and apps are.
Wouldn't I have the same quadratic growth (if not worse) if each community were to self-host their app view and relay?
> because you don’t want to teach each app to crawl PDS’s and subscribe to them
Why not?
If I want true decentralization, that means no central component. For the same reason that communities and individuals host their own RSS readers, each community will in the end also have to host their own relay and app view.
The benefits of decentralisation, including fault-resistance and censorship-resistance, can only manifest once every community is self-hosting their own relay and app view.
Maybe we’re just ideologically misaligned here. I think every single little community hosting a copy of every single app is insane, and not where I’d like to end up. It’s like the extreme end of the spectrum compared to centralized Web 2.0. I think atproto’s ethos falls somewhere in the middle — community is mostly a “soft” primitive, and there’s only so many full-scale “copies” of some app as there are strong opinions+funding bundles that motivate their existence. So maybe not too many for large scale ones.
> Maybe we’re just ideologically misaligned here. I think every single little community hosting a copy of every single app is insane, and not where I’d like to end up
Well, it's where we used to be — and it solves most of the issues of the modern web. Forums, blogs, IRC, teamspeak, gaming servers, etc, it all used to work relatively well with that approach.
I don’t think the problem I want solved here is replicating forums, blogs, IRC, Teamspeak, or gaming servers. I want something a lot like Twitter but with some way to take my stuff and leave if an asshole takes control. I don’t want Mastodon, because from what I’ve seen of it when friends link me stuff from it it’s extremely clunky and slow. Plus, whenever I’ve gone to create an account I’ve been presented with a huge list of servers to chose from, many of which seem to be focused on a specific topic, which makes me think I need to pick which community I want to be tied to with minimal knowledge.
My immediate question while reading your post (as someone who doesn't know much about ATProto) was "but where is the box for Bluesky?".
You didn't draw a box for Mastodon either, but my understanding is that it'd encompass all the individual instance boxes in the Mastodon-brained diagram. I think if you were to draw a box for ATmosphere it'd encompass everything in your ATProto diagrams. But what about Bluesky, Eurosky, etc? Are they "apps" in your diagram? I don't think so because I'm pretty sure they also host users' data. Are they the dotted "hosting" boxes? What are these things even called? Apparently not "instances"; are they "services"? "Networks"? "Providers"? Something else?
Bluesky is two things. There’s “Bluesky hosting”, and there’s “Bluesky app”. Conceptually and on the network level they have nothing to do with each other. These are different pieces of software running on different stacks and they are agnostic of each other. Bluesky the company happens to run both because it’s kickstarting this whole thing. But you can swap hosting (I just did) while using Bluesky app, or you can keep Bluesky hosting but use other apps in addition (like Tangled) or instead of Bluesky (like Blacksky).
Eurosky is a hosting provider primarily. They happen to also develop an app (Mu Social) but afaik currently that’s just a skin for the Bluesky app (it talks to Bluesky app API). Nothing stops them from removing that dependency (like Blacksky did) though and making it an independent forked app though.
So the answer is — companies and organisations in Atmosphere often provide services for different roles in the system. Some do just hosting, some do apps, some do other kinds of network infrastructure that is used by many apps, and many do multiple things at once.
> 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.
An "AppView" is the API server that most clients connect to that aggregates data from the network and serves it in a more useful way. mu.social still uses bluesky's AppView (api.bsky.app).
The name is confusing. I thought clients were appviews myself for a while.
I kind of started calling them all “apps” with true appviews being “independent apps”. I think sometimes it makes sense of think of this as an implementation detail. For example, Mu could actually switch to its own database if they do a bunch of technical work in the future. From the users’ perspective, it wouldn’t be noticeable.
> All of this goes away if we just do P2P social media.
This is the wrong way to see it. There is no "Best and correct" solution, only solutions with different trade-offs. ActivityPub/Mastodon/Federation makes sense in some cases, "pure" direct distributed P2P makes sense in some cases, one central server makes sense in some.
Bluesky/ATProto just made different trade-offs, for different use cases, some of which wouldn't have been possible without the architecture they ended up with, which sibling commentator expanded on exactly what.
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.)
> They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
Interesting. I'm an architect by title because my employer doesn't have the career path of a "senior specialist who really knows their stuff and wants to keep going at it". No. We have only two paths: either Manager (not interested in the slightest), or the almighty Architect. Every time I'm forced to architect something, that bit about the bottom line comes to my mind.
I'd say an architect is kind of the opposite from a specialist. The specialists cares about the stuff only they know. The architects care about the stuff everybody should know.
Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.
This doesn't work for intermittently-online, battery-powered, CGNATed mobile devices, and that's what people are using in practice.
The Google / Apple walled gardens don't make it any easier, but even without them, the fundamental issues of battery life and intermittent connectivity don't disappear, walled gardens just force you to design around them instead of hiding your head in the sand and pretending they don't exist.
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.
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
Someone has to archive the data, right? Perhaps the complexity has been pushed to the AppViews?
If I read a post from a month ago, how will my client know how many likes it has or what the replies were? Without reverse links, someone has to look up in a database of all AT actions for likes/replies pointing to that post.
Contrast with the inbox/outbox forward/reverse linking model of activity pub.
AppViews already had to archive whatever data from the network they cared about. The change just means that an AppView won't be able to infinitely backfill from any relay, you either need to find a relay that archives all the data you want and backfill from that relay, or you'll need to backfill by querying pds's directly. Or you could just not backfill at all, your AppView can do whatever it wants to really. Clients always talk to an AppView to get information about the network, the AppView manages the building of reverse links, the relay doesn't care about the hydrated state of the network, its just a stream of events which occur on the atproto network.
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.
If $30 a month is too much for you, then you probably should be doing something other than trying to run a relay. It is just not a significant amount of money.
$30 a month is a pretty massive costs for such a program. Why does it require such a beefy VPS, is it just the initial bootstrapping that requires such resources?
Because if you want to relay every single public event for every single user on the entire atproto network in real-time to many consuming apps and services… that's gonna cost something. Not that it costs a lot, but to expect what a relay does to be infinitely cheap is to not understand what it's doing or why it's doing it.
"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
And I honestly think this is one of the fundamental problems with the push back towards protocols and decentralization. We're overestimating the bandwidth and capabilities of the average user and we haven't fixed the problems that pushed everyone towards centralization in the first place.
Take me, for instance. I am not only capable of running my own Mastodon or Atproto data server+relay -- I'm technically capable of writing my own ActivityPub or Atproto app.
But I'm currently sitting with accounts on bsky.app and mastodon.social -- the biggest most centralized "instances" (yes, I know, but it reasonably describes the problem). This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
And this is doubly and triply true for the average person who doesn't have the technical abilities I have.
As a result, both Mastodon and Bluesky are still practically centralized to a large degree. An overwhelming majority (more than 90% last I found data) of Bluesky users are hosted by bsky.app. Similarly on Mastodon, a large plurality of users (~20%) are on Mastodon.social. Mastodon's obviously doing better than Bluesky in this regard, but it also has about a quarter of the overall traction, and I'd honestly put that down to Bluesky's apparent centralization which makes it a lot easier for people to join and wrap their heads around it.
This isn't about "average user". Relays have nothing to do with using atproto as a user. They're about developers making new apps.
By "most people" it's implied we're talking about most people who want to run a web app in their spare time. Do you mean a different definition? If you want to run a web app (which is the only reason you'd want a relay) and you're able to pool with ten other developers who want to do the same, you can make the cost to $3/mo. Is that feasible? What do you normally pay for web app hosting?
And again, if you're a hobbyist developer, you'd just use a community relay that already exists and is free. I assume that, if you want to run your own, you have a specific reason to do so.
An average user does not need to run their own node for decentralization to work. It just needs to be cheap and easy enough for enough of technical users to run
I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.
- If you just want to use your domain name as a username, you set a DNS record.
- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)
- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.
- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.
- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)
>"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
I don't think that was a recommendation for people to do, but to demonstrate that it doesn't require much in the way of resources. That VM could probably host hundreds of people, since relays scale and de-dupe shared content.
If someone said that email or a personal website was inexpensive and could be hosted on a cheap VM, I don't think you'd make a comment like the above dismissing it as impractical: the idea is that if it's that cheap, then there are people that can host cheap/free (maybe ad supported) relays, similar to how cheap/free webmail exists today.
> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)
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.
Wouldn't you then not be able to see replies from anyone besides the dozen accounts your relay follows too? If I run a personal Mastodon instance and someone replies to one of my posts, their instance will send it directly to mine and I'll see it. My understanding of the ATProto architecture is that it doesn't support directed messaging like that.
The cost for consuming the firehose of the entire network is very low. So the actual cost that can blow up is storage and computation.
If you want to filter for events based on some heuristic (e.g. only from follows of server list), you can do that. You can then specialize that further. E.g. for ongoing threads that already pass your filter, you could add their IDs to an array, and accept all replies for those threads as well into your DB.
You already get a stream of everything so you can scale down what you write to DB to exactly the characteristics you need. Including keeping threads cohesive.
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.
I had seen the mentions of labelers, though it hadn't been clear that that was something general beyond Bluesky-the-app, thank you. This would have been helpful to have in the article, alongside the mentions of defederation. When people are asking about instances, sometimes what they want to know is how you solve the same set of problems they care about, so here are the solutions to those problems, etc.
> There’s no “defederation” because there’s no analog of “community instances” that may fight with each other.
If Bluesky specifically wanted to just not have its user interact with some other entity in ATProto-land would they be able to?
My impression is that the answer to this is "yes", because people are signing up to Bluesky and relying on Bluesky to hold on to their posts etc.
Similar to how Email is all federated but in practice a bunch of people use email from one of a handful of large service providers who (in practice, not necessarily for nefarious reasons) do end up blacklisting certain email senders.
The RSS-reader example feels a bit different on the ground because for a given user, "store a list of websites you care about" is not a complicated endeavor.
For the "short-form social media with algorithmic timeline" usecase (which isn't all atproto is about, granted!) "users self-host a thing to scoop up enough of the world's posts to then make a local algorithmic timeline" doesn't... doesn't feel very feasible, right?
I guess the blogspot comparison is apt... but if "full" self-hosting requires a relay with quite some juice ($30 is "cheap" but... compared to a pile of files to host your own blog...), then in practice we're going to see a heavy amount of centralization anyways right?
How is it any different than a centralized social media service then? Merely the fact that you can get a firehose from the website in a standard format? This was already the case with HTTP. The problem is that websites can leverage their power to make a locked-in ecosystem.
The decentralization is totally irrelevant due to the way it's implemented. The problem is that Apps are sticky, so app developers have undue power to control their users.
The "content hosts" "moderators" etc need to be completely cut out of the picture to be at the same level of censorship resistance as an RSS-shared blog. I can host a blog on my own computer, and you can subscribe to it without that many intermediaries.
Sure, you could say it’s a set of conventions on top of what you’re describing — that imo is sufficient to shift the incentive picture. It’s a firehose of typed JSON that’s canonically stored at URLs that survive hosting changes and can link to other JSON. It’s signed and verifiable and links to other JSON.
So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch.
I think that makes a big difference. Don’t you think?
New services don’t start with the same userbase because users don’t use protocols, they use apps. And for Bluesky that’s predominantly a single centralized app. If that demotes content from the “competitors” or even switches the protocol completely, you are stuffed. The apps are very much not equal.
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.
> 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.
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).
Well I think "can move later" makes all the difference because the initial choice doesn't matter to the individual user. It isn't even blocking. Most people don't know they're making that choice, and I think that's fine. In Mastodon, the choice is very high stakes.
Frontends and relays are far closer to “quacking like an instance.” That’s where your sysop’s power lives. The PDS itself isn’t very powerful - can’t meaningfully limit who you can talk to, for example.
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.
> This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).
A good measure for decentralisation is: Can your community continue using the service if the rest of the world disappeared? Can you still federate with other communities that might still exist? What else needs to remain for the service to remain useful?
With mastodon, all of that is trivially answered. With AtProto, I'm either 100% reliant on bluesky, or I'd need to spend tenthousands of dollars a month minimum to self-host the relays and app view.
How is that trivially answered with Mastodon? And what does "the rest of the world disappearing" actually mean in your example?
Everything I'm seeing about hosting costs in the current day and age is that the full AtProto stack (PDS, Relay, AppView) is roughly in par with hosting an ActivityPub instance of equivalent size (if not a little cheaper).
And with AtProto, folks get to pick and choose what slice of the stack they wanna host, and opt-in to more of it gradually as they see fit. With ActivityPub, you are either opting in to hosting an entire instance, or fully reliant on someone else.
I'm open to the idea I'm misunderstanding some aspect of ActivityPub, given I've not really explored the hosting side of all that deeply.
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 agree, with the state of things as they are now.
I prefer AP for one reason, it's more accessible to the people. I would prefer to see small computer organisations with member fees, and donations, that run their own little node, instead of huge monolithic components.
That's why I never liked bsky, because it was too monolithic. I never liked the monolithic AP instances either. If we're going to decentralize, let's properly decentralize.
As soon as something becomes huge and monolithic, it's a red flag.
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.
But really, I actually would argue the opposite: ATproto is (or at least, wants to be) more decentralized.
In the ActivityPub world, identity, application, and hosting are intrinsically linked. If I want to use Lemmy, I can either register a second, permanently separate ActivityPub account on that Lemmy instance, or ONLY use Lemmy to the extent my Mastodon instance knows how to send messages that Lemmy understands. EVERY new ActivityPub app is a new set of interoperability concerns, because each app owns its own identity and hosting. There's no way for my self-hosted Mastodon instance to provide an identity to a Lemmy server and then for that Lemmy server to tell that instance to host content on my behalf.
That's the bare minimum you'd need to match ATProto, at least in the version being told to me by the ATProto people. No idea if any of it applies to actually-existing ATProto, in the same way that actually-existing ActivityPub can't interop the way ActivityPub supporters claim it can.
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.
Google Reader had OPML exports and tried to export its social graph into Google+. On the other side of it many of the blogs in Google Reader had some version of FOAF or XFN to try to maintain social graphs through open standard "semantic web" good feelings.
A social graph is more than just data, it is trust, it is attention, and it is political goodwill. That's one of the most important lessons of the fall of Google Reader. It wasn't just that the technology was shutdown, but that it damaged communities when it shutdown. You can't capture communities that don't feel like they belong anymore, that no longer trust you because you closed their former town square.
I still don't see enough evidence if BlueSky itself shutdown that ATProto survives that shock culturally, even if it is built to do that technically. If Mastodon.Social, still the biggest instance, shutdown tomorrow a number of Mastodon instances wouldn't even notice and some of the ones that did notice would just as likely throw a party as lament the disappearance. That's a pretty big cultural difference, not a technical difference.
I agree with you but I think the technical capability intersects with politics here because anyone is able to make new stuff out of old data. That’s not the same as Google carrying it through to another Google product. I’m not aware of the FOAF/XFN stuff but it’s also different if that isn’t the entire graph perfectly preserved, easily queryable by everyone involved.
When developers feel empowered to revive products or fork them, I think that eventually seeps into communities. That it’s another way of doing things. It doesn’t happen overnight but this energy exists in the Atmosphere. Maybe loss of Bluesky is not survivable culturally at the moment, but maybe it will be in a few years as Atmosphere grows and matures.
I like Newsblur. It has some social tools that remind me of Google Reader at its peak. I have friends that like The Older Reader. It has some social tools that remind me of Google Reader at its peak. Neither of those social spaces communicated between each other.
What we have is a "diaspora", what was once one larger community has moved on to a lot of smaller, more disparate spaces. That's not necessarily a bad thing, but a lot of trade offs were involved, a very large community feeling was lost, and a lot of intangibles were lost (friends with Gmail accounts that could easily follow and interact with us in Google Reader but are lost trying to navigate any other RSS Reader, for instance).
This blog does a great job of explaining the architecture. In practice though I’d thought the “problem” was that Bluesky (the corporation) runs the main app and hosts almost all of the user data.
So at the protocol level it’s decentralised, but in practice the system is still very centralised (in terms of who controls it).
Not saying this is necessarily Bluesky’s fault, but it’s how things have played out so far right?
The "problem" is that people are looking for problems. This "problem" isn't specific to Bluesky, ATProto, or anything else. Look at any organization: profit, non-profit, group of volunteers, etc. and you'll always find someone that folks have a problem with.
I'm not an investor and have no conflict of interest with Bluesky beyond being one of the earliest of users. I also understand the protocol, the company, the website within my own limitations.
The site (and app) works just fine. Folks are really focused on finding problems rather than coming up with bigger and better solutions.
Note: the majority of folks don't want an ad-hoc p2p solution like lemmy or mastodon. they want their content in one place, and they want to be able to hold that entity accountable. Because of this, p2p social networking will never take off. I've seen more drama surrounding both Lemmy and Mastodon than I have ever seen with twitter, reddit, facebook, etc. combined.
That's my 2 cents. Also, apparently my spouse feels the same way. So do my friends.
There are other apps, other user data hosting (including personal hosting), and other backend services.
It is decentralised in both theory and practice.
The only thing you could potentially say is that because Blue sky run the biggest parts, it's not decentralised at the community or mind share level, but that's changing.
Does really do a great job? It just says there are no “instances”, it doesn’t explain how the architecture circumvents all the troubles that it leads to such as auth, sync, discovery, etc.
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.
Aren't the vast majority of web pages nowadays signed? Almost nobody downloading and storing the content on websites will retain these signatures, but they exist and can be verified with enough information. IMO archive.org and archive.today should, to prove they haven't tampered with contents.
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.
The OP's article and replies in the comments here seem like someone who's comparing an idealised view of what Bluesky could be versus a cynical view of what Mastodon currently is. This troubles me because it overlooks the massive problems with Bluesky as it currently exists. It is hyper-centralised, much more so than Mastodon ever was. Virtually all users have their data stored by Bluesky PBC, aggregated by Bluesky PBC, access it through a website and app made by Bluesky PBC, and most crucially, are subject to the moderation decisions of Bluesky PBC at every turn. And I don't think it's a stretch to call Bluesky an “instance” here.
Now, sure, you can use a different instance for most of these services. And that instance can interoperate with Bluesky. But that's the case for Mastodon as well, and the real difference is the Fediverse has had to live with the painful compromises that come with the anarchy of the real world. I think Bluesky will discover its own version of defederation soon enough. I don't think “ah, but you technically theoretically can still interact with people even if you can't see them on your instance” is worth all that much.
Facebook is not just a "evolution of this concept". I would argue they, along with Twitter (currently know as X) and other similar service is completely different from blogs.
The main different is the designs Facebook has employed manipulated their users to adopt this "scroll down" method of reading. Each item of information is only displayed just a few seconds on user's screen, unless user stopped scrolling at the item they really interested in (and then maybe tap to open it).
That's not the same design used by blogs. Think of blogs as mini news sites, it encourages their readers to open the content in a full page to read it without interruptions. And, the readers has to calm their heats down to read long statements, this costs time and demands focus.
If you port the design used by blogs and apply it to display Facebook posts, that will be user-hostile, because user has to click each post only to read a potentially very short content.
The opposite is true too. You can't encourage user to "scroll down" a wall of long texts just to read the next wall of long texts, because that will be exhausting. You can't even create the anticipation that there's more stuff down, because that will just manipulates the user to keep scrolling down and skip.
That's why I think even you technically can aggregate blogs and social media in one app, you should probably be careful about it.
I've wondered for awhile why someone hasn't started the Blogger.com of ActivityPub/Mastodon: 1 "instance" per person, no weird complicated group dynamics, the service handles all the technical details, the user draws from the same cohort as the people who signed up for Blogger blogs in the early aughts.
If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage; like, I can see how Mastodon keeps chugging along no matter what companies get sold to who, but I don't see how ATProto survives the death of Bsky.
My bad, I misread your post as asking about single-user atproto "instances" (which confused me) but you said ActivityPub.
I still don't quite understand your comment.
>If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage
The advantage of atproto is that it's literally "the web". Every app can aggregate from entire network, there's no isolation by default. It reduces to the degenerate smallest case just the same — you can have a single-user app that simply displays content from your PDS. But you can also start aggregating things (e.g. comments left by other users, which are stored on their PDS's). The whole big idea of atproto is that every app is effectively a CMS for app-agnostic "model" web.
What is the concrete thing bothering you? AT is already in the IETF process. It's not some weird corporate thing.
You literally just set up a Mastodon server and only have a single user. That's what I do, and as far as I know it's the only solution.
A "lite" version of Mastodon that dispensed with all of the complexity involved with managing multiple accounts and was optimized for a single user might be nice but with a hosted account you're paying for data storage (which Mastodon seems horribly inefficient with) so in practice that extra complexity is moot.
Right, my point is, someone should stand up a service, like Blogger did for blogs, which were also trivial for people like us to set up and run on our own.
The thing there is it destroys the objection people have about having to find and fit in with a particular Mastodon server community.
It also makes Mastodon look more like the original blogosphere and less like Twitter, which is a good thing.
Atproto apps are not like an RSS reader that runs on the users' computers and connects directly to the sources of content.
Atproto apps are servers that control, filter and shape the content they serve to readers.
Atproto apps can censor, shadowban, show ads, algorithmize the feed into anything it wants. The user is powerless and the creator is a victim that can't do anything besides crying.
The fact that any person can host their data anywhere is completely meaningless since they have no way of distributing that data.
That’s the whole point of “apps”. Apps are opinionated points of view / prisms over the network. Of course they’re able to apply their own moderation decisions. That’s how the whole mainstream web works in general — you can’t even get an unmoderated app into App Stores.
The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.
That’s not really true. For one, you can have different AppViews which don’t do that. The feeds can be algorithmic however you the user want — multiple apps means you aren’t tied to what one central creator desires for those algorithms.
- 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.
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.
Not necessarily – there are some activitypub instances without hostname, directly on IP addresses, and there are even some running in private DNS roots.
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.
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.
This is the real strength of ActivityPub compared to ATProto. I follow a lot of accounts on mastodon, and only a handful of them are on mastodon.social. Globally though looks like 1/4 of the accounts are there.
If the instance goes down, the network stays up and continues to work, minus only the accounts on mastodon.social. This is not the case on bluesky afaik. They got DDosed a few months ago and the whole network was down because of it. https://news.ycombinator.com/item?id=47802330
In ATProto there aren't 'instances', and its technically 'decentralized' but theres really only bluesky.
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 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.
Not really, considering there aren't that many app servers. Each PDS sends out its events, those events are picked up by whoever wants them, mostly relays but some apps might directly subscribe. The more apps in play, the more connections, but it is not the case that for every new PDS, every other PDS now has to open an additional connection. It scales with the amounts of apps, not PDSs.
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.
>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.
Okay, but that's always the case when you get banned from a service. The difference here is that it's possible to build a competing service with different moderation decisions being a lens over the same data.
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.
That goes to the heart of the issue. Bluesky's dependence on VC money and for-profit structure means it has a conflict of interest with long-term survival and independence of the protocol. But that might be fixable.
The mitigation is of course more companies and open source projects getting involved. As far as I understand it, the protocol is pretty well designed, and there is a bunch of open source out there already. It just needs more people to get involved.
But the article pointing out that you can migrate your Bluesky account to a thing called Eurosky was actually news to me. As is the existence of non Bluesky owned applications on top of atproto. I might give those a try actually. It seems a lot has happened since I last looked at this stuff a few years ago.
That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well. The more independent atproto software projects are out there, the harder it is for Bluesky to make breaking changes. That naturally pushes for some independent governance. I wouldn't be surprised to see that happen over time. But worst case, there could be some kind of fork/split of the network.
It would be interesting to see some attempt to bridge with other networks. A mastodon / bsky hybrid. Why make people choose? Despite X's demise, it's still X versus everything else. There's also Meta's Threads and a few others. The whole "not X" space fragments users over multiple networks that sort of could federate if they would but they really aren't. I think Threads is nominally mastodon compatible at least but actually federating is a bit frowned upon by Mastodon users.
And while we are "at" it, why not support email as well? Which is the og. federated communication network with essentially all internet users as active users. It's not perfect, but nothing better ever managed to replace it.
Separating identity from protocol is a good design choice. Cross protocol federation is a logical next step. It's all about receiving content from people, not about staying in walled gardens that belong to share holders.
>It seems a lot has happened since I last looked at this stuff a few years ago.
Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog
>That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well.
Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.
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.
ATProto is good at what it was originally designed for: decentralizing Twitter. It allows a gradual introduction to the network and ensuring you have control over it at the same time.
When a user decides to jump ship from mastodon.social run by Mastodon gGmbH to another server, they are using a similar but different service. It has different moderators, different emotes, different themes, different federation list, etc. They all have a different flavour, and, for better or worse, they come in a single package.
When a user decides to jump ship from bsky.social run by Bluesky Social, PBC, first of all... what does that even mean? Do you want an alternative storage (PDS) for your data that will still be read by Bluesky the app and Bluesky the relay? Do you want a different "service" (what @ calls AppView) which is then not Bluesky? Do you want a different handle other than @[username].bsky.social? If that's the case, you don't even need to faff around with alternative PDSes or AppViews, you can just slap your domain on it!
Mastodon invites users to federate by giving it a character. Bluesky slices and dices it to a point where the only reason you would bother considering decentralisation is for ideological reasons. And to that point, Bluesky has consistently prioritised building their own service up rather than decentralising. You still can't export photos and videos you've uploaded (through their AppView). Until some time ago you weren't able to return to using Bluesky's PDS once you've moved away. And of course, because ATProto operates out in the open, features such as bookmarks that are supposed to be private doesn't even go through the ATmosphere. (I'd love to know if these are exported but I don't know of a way to open their ".car" file which is neither a plaintext nor a zip file.)
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.
Right, which is why my article has this paragraph:
>I say “Mastodon” here because if I say “ActivityPub” instead, a crowd of people will show up and say that actually what I’m describing is how Mastodon chose to implement ActivityPub. Whereas ActivityPub by itself does not really specify how to actually use it in practice.
I understand there's other ways to use AP, but when people say "where are Bluesky instances" they are specifically comparing AT to Mastodon's AP topology.
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.
No tools meaningfully "default" to it — it's something you set up at the app level. And no, it's not hard to change, it's literally a single string constant that you put yourself into the code. If I were making a serious app, I'd likely run one myself for peace of mind. It's not difficult, you just spin up the Docker instance with it.
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/
TL;DR: people complaining why there aren't bluesky instances are misunderstanding atproto. There are no "instances" like in Mastodon, atproto is different, it uses many "hostings". Except those hostings are just instances of the hosting software. And there in fact aren't that many.
But you're just Mastodon-brained, you don't get it!
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.
I read the post a few times, but I still have some questions that I feel weren't answered, probably because I lack the deep protocol knowledge. For context I run a 'single-user' Mastodon instance, and I don't really see how that is any different than either the blog or what ATProto offers.
What I'm most confused about is that an 'instance' has just shifted elsewhere. Sure, with AP you have to choose an instance, or just go with the default mastodon.social. AT doesn't seem to have instances but, you have to choose a host, and I suppose there's probably a Bluesky default host. I can't really see how that is any different. You probably could self-host an AT host as much as you can self host an AP instance for yourself (I run mine on a $6/month VPS).
The second point I don't quite get is that these apps don't seem to solve the same issues that instances do, and I believe this is the part where I'm lacking AT Protocol knowledge. If, in running my own host, I need to have software that handles access control, authentication, follows, etc, then I'm running an instance, even if it's called something else. If a host stores only data, then at some other place there is software that handles follows, access control, etc; then that software is equivalent to an instance, even if it's called something else.
When people ask where the AT instances are, I think about it like this: with mastodon (or any other AP app) I control not only my data, but the code that handles it. With ATProto what it seems like to me is that I can control where my data is, but not the code that handles it (considering the main criticism that you can't run bluesky 'instances', even if instances are called something else). That's why I think 'There Are No Instances in atproto' doesn't convice me. There might not be something called instance or it might be broken down in different components, but there is at least something equivalent. If you have a million different hosts but this data is handled by a single component hosted by someone, then you can't really say it's decentralized.
Sure, there are technical differences between both protocols, but from a user perspective without protocol knowledge, it doesn't seem any different from the outside. You download the app and use the default host/instance and if you don't want to be on the default one you have to get technical regardless of which protocol you chose.
One bit of feedback is that the somewhat 'snarky' comments directed at ActivityPub might put off the target audience of the post, that are precisely the people who ask where the instances are. But all in all, I feel the article did a good job of explaining the differences (besides the few points I mentioned earlier) and clarifying that ATProtocol has a clear separation between the data and the presentation of the data. While it's something that AP can do (my instance works with mastodon, with pixelfed, and other 'Apps' and my data is in a machine I control), it's not the default and data tends to be tightly coupled with the big instances.
My uninformed(about this particular enterprise) but educated guess: if tomorrow VC funding evaporates all this network cease to exists. I guess based on feely that 80% of all of these Relays, PDS, Apps including, Bsky are all from few if not one company, meaning centralized behind the curtain, but decentralized evangelism. It is very possible I am completely wrong, and so be it.
So all the content servers under one big auth infra; you could post anything on relays and apps, doesn't matter because your account is banned and nobody has the key to fetch those invalid data from relays.
I mean, that's how it went, after all. BS/AT is a fine replacement for twitpic-era Twitter, but it's not a locked-open decentralized social media.
The AT Protocol has a federated network architecture, meaning that account data is stored on host servers, as opposed to a peer-to-peer model between end devices. Federation was chosen to ensure the network is convenient to use and reliably available. Repository data is synchronized between servers over standard web technologies (HTTP and WebSockets).
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.
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?
> Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.
And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.
> 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.
Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.
> 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.
True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!
> 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?
There is nothing in the protocol enforcing this and this expectation has been broken in the past.
This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!
---
I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.
OK, but that raises a question. Can I do that right now? If so, I don't understand why more people are doing this. When I looked into this I definitely didn't see anything like this.
> And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.
I like the concept of W3C DIDs, but it's a little soured for me that there was no real solution to the PLC DID problem. It is, quite literally, the exact opposite of being decentralized. (IIRC they do support one of the other DID methods, but it's not default, and I couldn't figure out how.)
Which seems like a common theme. You can absolutely fix the downsides of the Fediverse, it just requires you to reduce how decentralized the network is :)
> Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.
While this is technically correct, Threads is not widely considered an instance in the Fediverse and is missing in "instance lists". Threads is less like a part of the Fediverse and more like a centralized social media service service that supports interoperability with ActivityPub.
> True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!
This is cool but not relevant. I'm more specifically talking about Bluesky vs the Fediverse here, when referring to the protocols. Obviously there are also uses of ActivityPub that are not Mastodon/Misskey as well.
I haven't seen another ATProto application that I found interesting enough to try yet.
> There is nothing in the protocol enforcing this and this expectation has been broken in the past.
I never suggested it was literally impossible for someone to do it... but the concept of a "Mastodon" app is inherently agnostic to the instance in a way that Bluesky's apps are not.
> This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!
Sure. I'm suggesting you can't actually have decentralization without the possibility of all of ActivityPub's downsides. You can't use technical means to fix the social problems with decentralization; you can only defacto centralize things.
> I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.
ATProto is decentralized, at least to some extent.
You're refusing to look at the ATmosphere network and instead compare Bluesky to the Fediverse. I can instead compare mastoson.social to the ATmosphere and draw the inverse conclusions. What's the point?
Uhhh, I'm comparing Bluesky to the Fediverse because that's the main applications of ActivityPub and ATProto? I don't care about the broader ATmosphere.
How is comparing Mastodon/the Fediverse and Bluesky unfair? Are you kind of admitting that Bluesky isn't actually practically decentralized by suggesting the AP analog of Bluesky is the largest Mastodon instance rather than the federation of them? This seems to contradict what you and much of the marketing around Bluesky says.
People use apps, not networks of apps. Saying you don't care about the broader ATmosphere is exactly the same as saying you don't care about the broader Fediverse. That's fine, but then let's compare apps to apps instead of an app to a network. How does bsky.app compare against mastodon.social? (Actually let's not do that, because comparing a single app in a decentralized network to a single app in another decentralized network is pretty boring).
> Are you kind of admitting that Bluesky isn't actually practically decentralized
The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.
I really dislike you trying to turn this around on me like I'm the one spewing out gotchas. I'm not. You are. You did it with Threads and now you're doing it again with this nonsense.
I'm comparing two supposedly decentralized microblogging platforms, Bluesky and Mastodon (and compatible microblogging software.)
The things in your post don't hold up. For example, people log into apps. OK. So when I log into my email account using Thunderbird, that's decentralized. Right? Literally I am using a client to connect to some IMAP+SMTP server. Couldn't be more decentralized.
So now let's say I log into gmail.com. That's still email. Is email still decentralized with the existence of gmail? Well, it is less so than it maybe should be, but absolutely! Because I actually use Fastmail. That's what a federated network looks like.
When I log into Matrix, I still use Element regardless of homeserver. I can use any instance of Element, or install it to my machine. But still, it's Element. That's what a federated network looks like.
Not all decentralized things are federated. Some of them are, for example, peer to peer, and many other architectures.
I am ignoring the broader ATmosphere because it is not part of Bluesky the microblogging network. There are also plenty of ActivityPub applications that are not Mastodon-compatible microblogging networks, and I'm not talking about those either. I'm not talking about, for example, the network of Peertube instances that are also using ActivityPub.
I fully admit that I am not an ATProto expert, but if you're not running a Bluesky compatible AppView that speaks the Bluesky schemas, you are not participating in Bluesky, which is what I am talking about specifically.
I have used the terms "ATproto" and "ActivityPub" only in the context of Bluesky/compatible and Mastodon/compatible. That is it. If you wanted to argue about something else, it is not me pulling a gotcha on you to refuse. I just simply don't care, and you are not taking the hint. It's my damn comment thread, I know what my intended scope was. I know, too, you must know that Bluesky itself is supposed to be meaningfully decentralized, such that you can indeed run your own entire appview stack and still be a part of Bluesky, so you must understand that what I am doing is inherently an apples to apples comparison.
Yet when I log into Bluesky using a Bluesky app, what I get is the Bluesky appview and Bluesky moderation service. This is because Bluesky is substantially more centralized than the Fediverse. You can kick. You can scream. It doesn't matter. Bluesky. Is. Centralized.
> The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.
With all due respect, to the extent that there is any, no thank you.
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.
> Blacksky is literally the only such example of alternative infrastructure that I know of
That doesn't mean other places aren't doing so. As an example - here's a list of all the relays that mirror the ATProto network: https://atproto.at/relays
There's 16 relays by my account, of varying sizes. Of course, you don't have to query a relay - you can look at the Personal Data Servers (PDSes) directly.
* And more, like the TikTok clone I can't remember the name of, some more blogging platforms, a (fairly dead) Hackernews clone, some games, etc.
That isn't even mentioning all the Bluesky clones like Blacksky, Eurosky, Northsky, and W.
Each of these shares the same account - the account on your PDS, which you can self-host on any computer with an internet connection. I run mine alongside my smarthome server. Because they share an account, they interop - I can subscribe to a blog on Leaflet and have it show up in my Bluesky feed.
These services can fetch data from your PDS directly, or they can look at the Relay and get the full view of the network - but frequently, they don't need to.
Bluesky went down a couple months ago and many of these services were all perfectly usable, because they used the protocol but not any infra provided by Bluesky itself. The people who couldn't access the network were the ones who relied on Bluesky to host their accounts - which is a majority of the network, sure, but in the same way that Mastodon.social is a good chunk of Mastodon's network. I was able to use Blacksky to post onto Bluesky while Bluesky was down, because I was self-hosted.
Now both Eurosky and W have launched; Eurosky is aiming to be fully independent this summer and I _think_ that W already is? W's a bit more closed-off than most of the other projects I named, going directly after Twitter-as-it-is-now and not Twitter-as-it-was (hence why they chose W to compete with X).
Relays are now cheap to run, but they don't enable you to actually be independent. You would need a proper AppView for that. Eurosky is actually not independent at this point.
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?
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.
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.
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.
was that lemmy.world? As you have discovered, some instances are full of drama. Such is the nature of decentralisation. If you don't have some parts of the network full of drama there's probably a central entity suppressing it.
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).
Every time I see a post praising ATProto on HN I cannot shake the feeling that this might be the product of a concerted (and VC-backed) marketing effort.
ATProto is "decentr-washing" as far as I'm concerned. Even if you self-host as much as possible, if Bluesky's relay declines to crawl your PDS, or its AppView declines to index/serve your records, then to essentially the entire audience you simply don't exist. did:plc controlled by a Swiss Verein, as if this could be a reason to drop all self-sovereignty worries! Credible exit was actually always working well on ActivityPub already, and if you self-host your instance you probably won't even need it anyway. Regardless, there is FEP-ef61 now, so I genuinely don't understand why to prefer ATProto over ActivityPub, even in the foreseeable future.
Let's not even talk about Nostr, that natively solves all the issues that ATProto seems to care about. Nostr is IMHO a much superior technology, unfortunately plagued by ecosystem/people and Bitcoin-dictated technical choices (BIP-340 keypairs, brrr).
We could develop an all in one stack that handle relay, AppView and iOS / Andriod / Web apps to serve small communities and have the Mastodon instance vibe, except one identity could appear on different instances at the same time. It doesn't exist yet, but it's possible.
> Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly.
I feel like you've (perhaps purposefully?) misinterpreted "instances" just to plug ATProto specifically at the expense of ActivityPub (and RSS, a bit). I think you lower yourself by doing this:
1. it forces you to omit and contort the interesting technical truths about ATProto and Activitypub, like Relays and their pros/cons for ATProto and account migrations and pros/cons for ActivityPub
2. it creates unnecessary conflict and criticism and seems unnecessarily divisive for 2 platforms solving problems in such a similar space
It's also just seems a bit silly: why would you assume that when someone asks "where are the instances?" they're not using the common mainstream use of the word "instances", like, servers, or running software, or VMs, or containers?
Sorry if this is overly harsh or I've misunderstood, but it gives me a strong vibe that it was motivated by disdain and frustration towards ActivityPub and ActivityPub users rather than wanting to legitimately inform the world about ActivityPub.
I did enjoy the diagrams and the explainers though! I just felt like the subtle digs and pops at activitypub were an unnecessary distraction.
I'm being a bit cheeky in the article's tone but I am fairly confident from discussions in the past that "But where are Bluesky instances?" is a common question which usually demonstrates a misunderstanding of the architecture where "having instances of an app" is seen as a measure of decentralization.
My article was an attempt to dig at this specific misunderstanding by comparing it to "But where are Google Reader instances?" which I think illustrates its absurdity. I genuinely do think that the two pictures I provide close to the end clear this up in a way a lot of early atproto/ActivityPub discussions completely gloss over.
Re: Relays, I wrote here on why I didn't include them: https://news.ycombinator.com/item?id=48600963. They're kind of incidental perf optimizations rather than essential to the model. In the post, I wanted to focus on the model.
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 could see "Bluesky AppView" has similar semantic as Mastodon instance: network, moderation...
The difference is on ATProto, when I get banned, people must switch to another "AppView instance" (could be reusing the same Bluesky AppView stack) to interact with me. I summary, my data is not lock in, but my audience could be.
On the other aspect, Bluesky AppView is only a small part (a microblogging network) of the bigger Atmosphere where we can create different AppViews for different use cases, e.g. publishing (leaflet.pub), code repository (tangled.org). Users can use the same handle and PDS for these AppViews.
Yeah I wanted to say that. From a user's point of view, it sounds like the AppView is the instance. If you disagree with the moderation, you can move to a different AppView (that may use different relays) but keep your PDS.
Whereas with Mastodon your PDS is your AppView, so if you leave the AppView you lose your PDS (and have to somehow export it).
Is that correct?
Yeah, I have the same understanding. On Mastodon, an instance is an all on one package. On Bluesky, each component can be deployed separately. The nuance is Bluesky PBC own the Bluesky (iOS, Android, Web) apps, the AppView and the default PDS hosting, I could say it's centralized by default and decentralized at will.
> I could say it's centralized by default
I'm not sure that's totally right, though, because I (using the entirely default bsky stack) can and do regularly interact with people who are using different PDS and AppView's (like, I can interact with Eurosky and blacksky accounts).
I think the thing that is centralized by default is the bsky moderation layer.
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'm one of those "is it decentralized yet" people and to me the real concern is the AppView since I assume that's where censorship would be applied if it ever happens. People keep telling me about PDSes but I don't care about controlling my PDS if other people can't see my posts.
I wouldn’t say censorship alone is the primary motivation here so I’m a bit wary when people bring it up. But the way to think about it is that your data being on PDS is the mechanism that creates a market opportunity for other apps that, among other things, differ in moderation strategies.
Concrete example: Bluesky banned a person, and Blacksky community disagreed with that ban. When Blacksky switched http://blacksky.community app to have its own complete stack (including its own database), that person’s posts became visible there (despite them being banned on Bluesky app) because they reversed that moderation decision. This was possible because the data for this person’s posts still lives on their PDS.
In general, the data being “pulled outside” products is what enables new products (or forks of products) to come onto the scene and immediately begin competing because they don’t have to solve the “cold start” problem. If you log in, all your stuff is “already there”. And it’s the same shared world so the community doesn’t get forked. You’re just looking at the same underlying data under a different lens, and products act like lenses rather than boxes.
This doesn’t mean that “censorship” can’t exist (every layer can ban you, as always) — but it means that every layer of the stack has opportunity for competition that isn’t possible with centralized platforms. In fact, arguably, it’s more flexible than a Mastodon instance because you can’t fork a Mastodon instance “with all its users” and offer a version that reverses some moderation decision. In atproto, you can.
> I don't care about controlling my PDS if other people can't see my posts.
Isn't that similar with Mastodon? Someone on an instance that does not federate with yours will not see your posts, and I guess someone on an instance that would censor you would not see your posts?
That someone would have to change instance if they disagree with the moderation, and doing so is more painful with ActivityPub than with ATProto, right?
Disclaimer: I have no skin in this game, I don't use social networks. Just interested technically :-).
It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance, or pick one that aligns with your views and interests, such that the bulk of moderation is handled for you in terms of which instances you federate with etc.
> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky.
No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.
I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?
You can trivially host an appview for your atproto app on your own. I have a hobby atproto app, and I host an appview for it. I mean — an “appview” literally just means “a server with a database that ingests stuff from the network”. It’s not some mysterious thing or some concrete distribution. It just means you’re aggregating stuff into your database.
It’s just as cheap as hosting any webapp.
But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense.
That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records.
Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people).
To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that.
People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.
Say bluesky is applying content moderation techniques I disagree with.
What steps do I have to follow to get the majority of users to see my content?
Another example. Let's define decentralisation in terms of bus factor:
How many companies could go bust today before most users would notice?
> To make the comparison fair
Okay, so let's build that, then we can actually talk about building a decentralized network on atproto.
How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?
From what I understand, in bluesky the PDS does not know about replies to a post. So I'd need to scrape the entire network anyway, no matter what, even if I only store some of it.
And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?
> And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?
They could rely on some relays to build their AppViews. The flexibility is already there.
I feel like you're missing the point of a decentralized protocol if at every step you suggest to use centralized services instead.
> What steps do I have to follow to get the majority of users to see my content?
You can’t “get” the majority of the people to see anything, that’s not how anything works. Neither on centralized systems, nor on Mastodon, nor in real life.
On a centralized platform, if you get banned, there are no steps you can take. Your account is down — goodbye.
On a Mastodon instance, there are also no steps you can take. Your account is banned on the instance — your entire identity goes down with it.
On atproto, it depend on whether you’re banned at hosting or app level.
If you get banned at hosting level (usually something clearly illegal would trigger this), you’d have to find another hosting (assuming apps haven’t banned you too).
If you get banned at an app level, people will see you through different apps. You’re right that this presupposes that there are apps that (1) people use, that (2) haven’t banned you, (3) and that display the same type of content.
But, even if you’re looking from solely censorship resistance perspective, atproto at least enables competition in moderation space to happen. If enough people disagree with the lens, it is possible to build a an alternative lens over the network.
This isn’t theoretical — there was a situation like this where a person got banned at Bluesky app, but the Blacksky community wanted to reverse the decision. When Blacksky got an independent app database running, they overrode it. But yes, this does require investment and a subset of community being interested in alternative moderation / features / etc. You can’t “force” people to hear you but there’s a market for alternatives.
> How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?
The realtime part is trivial. You just filter the stream of everything as it comes in.
Backfill would either require you to index the network yourself or to rely on existing indexes. You could use Constellation (https://constellation.microcosm.blue/) to fill up threads (query by thread root ID), and you’d hit the user’s PDS to fill up their profile page.
You could actually see that in practice now at https://reddwarf.whey.party/ which my article links to. It’s a Bluesky client that doesn’t have a server at all (and doesn’t hit Bluesky API). It’s lazily getting stuff on the client purely from PDS’s and from Constellation. It’s a bit slower than an appview-backed experience but it works fine.
Other people use many different mastodon servers but all bluesky users use bluesky
The difference between Bsky and Mastodon is that Bsky unbundles PDSes and App Views, while Mastodon does not.
Migrating to a different App View should be painless in theory (app views are not supposed to collect any state that is not saved in the PDS, not sure if Bsky does or not), and you can use multiple app views with one PDS. On Mastodon, you have to migrate both at the same time, and moving content across instances is not yet a fully solved problem.
The difference between the two is that Bluesky has a central audience with decentralized content, while Mastodon has a federated audience with federated content.
Blueksy holds all the power, while the users hold none, whereas with Mastodon has many separate communities, similar to the old-school BBSes, forums, IRC and teamspeak servers.
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.
Currently, just over 3000: https://blue.mackuba.eu/directory/pdses
There are:
- 221 with over 5 accounts
- 74 with over 20 accounts
- 19 with over 250 accounts
- 8 with over 1000 accounts.
And only a handful of those have open signups (13 with open signups have >50 users).
Many of them are actually ActivityPub instances with a PDS bridge, e.g., https://join.wafrn.net/
And most of the other open signup instances are also primarily designed as their own social network, just using AT proto as a compatibility layer, e.g., https://sprk.so/ https://haruhwa.com/ (which is an invite-based, snapchat-style ephemeral social network), https://surf.social/, https://pckt.blog/ (a microblogging platform), aesthetic.computer (a collaborative programming/art platform)
That leaves only bluesky, blacksky, eurosky, selfhosted.social, self.surf and npmx.social.
Even during Facebook's heyday, the unsuccessful diaspora/friendica/gnu social/etc networks had more decentralization than that.
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.
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 atproto app goes down and it’s open source, anyone can put it back up with all public data intact.
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?
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.
> blacksky, last I heard they were still working on a major piece?
While that was true, I don't think it's true anymore. I think blacksky is fully independent. Eurosky is currently in the spot you're describing (partially independent, but moving towards also being fully independent).
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.
Yeah that’s a fair clarification. At the very least I think Bluesky hosting should start doing something for automatic backups.
They're funding Fig to create and run a "full network backup" solution. What Bluesky really needs to do is figure out a way to get users to own their own backup recover key, whether personally or through some third-party service.
I'm sorry, just to clarify: in your scenario where the app/company is suddenly vaporized from the face of the earth, if that happened to Bluesky right now it would effectively mean that >90% of content currently published using Atproto would be lost?
No and yes and no / it depends.
Realistically, I can't say "yes" because I'm sure there's plenty of copies of entire network by now. They would be out of date but would have all old records. So that could be maybe 70% that's already backed up. I guess they likely won't include images/blobs. There's an ongoing project to build an always-available full archive with this specific purpose (https://atproto.com/blog/introducing-hubble-a-public-mirror-...) so it is also an active area of work.
If we imagine that nobody has a full copy today or is unwilling to share it, the answer would technically be yes.
I'd still say that, for an app going down, the answer is "no" because "Bluesky app" and "Bluesky hosting" are like two separate services. The point I was making was that specifically "apps going down doesn't destroy data". (The distinction between "Bluesky app" and "Bluesky hosting" isn't completely contrived because I'd expect the cost of running the app to be many orders of magnitude higher than the cost of running hosting.)
But if you pick a hosting company, and users don't have backups, and nobody does mirroring, then yes, hosting disappearing would destroy data. As with literally any hosting.
Yeah I'm kinda waiting for this. I don't like to join bluesky because I want it more decentralised but I can't join blacksky because it's only for black people.
I'm kinda hoping someone sets up a rainbowsky or something for us in the LGBT community. Now that I would join.
https://northskysocial.com/ might work for you!
You can have an account on Northsky and use it with Blacksky's appview!
Oh thanks! I wish they'd have their own appview but I guess that might take time.
I'll definitely try it out!
The blacksky servers also host myatproto and crypto anarchy PDS's, which are open to anyone
The obvious question is, which group gets dibs on "redsky?"
The Fixx https://www.youtube.com/watch?v=cit17Si-Vts
I hope it's shepherds
Blacksky is now fully independent and does not have any reliance on Bluesky whatsoever.
In fact, in cases where Bluesky _did_ go down, Blacksky was still working fine (if a little slow due to the amount of Bluesky people on Blacksky), and people were able to make posts and everything.
blacksky does now run the entire stack themselves
Can they? 99.8% of the Blue Sky app data is hosted on the Blue Sky company servers.
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.)
In Mastodon/AP, different instances talk to each other which creates the scale problem you’re mentioning.
AT doesn’t have this kind of issue even without Relays. This is because PDS never talks to another PDS so there’s no quadratic growth of edges. PDS only talks to apps, and there’s limited amount of apps on the network. And end users hit apps which cache stuff, so apps tend to take the user traffic hit.
Relays are helpful more on the app side because you don’t want to teach each app to crawl PDS’s and subscribe to them.
I didn’t dive into Relays in the article because they’re kind of a “next obvious optimization” but not really inherent to the model. There are other models like apps hitting shared backlink caches (like Constellation). Relay isn’t fundamental in the way hosting and apps are.
Wouldn't I have the same quadratic growth (if not worse) if each community were to self-host their app view and relay?
> because you don’t want to teach each app to crawl PDS’s and subscribe to them
Why not?
If I want true decentralization, that means no central component. For the same reason that communities and individuals host their own RSS readers, each community will in the end also have to host their own relay and app view.
The benefits of decentralisation, including fault-resistance and censorship-resistance, can only manifest once every community is self-hosting their own relay and app view.
Maybe we’re just ideologically misaligned here. I think every single little community hosting a copy of every single app is insane, and not where I’d like to end up. It’s like the extreme end of the spectrum compared to centralized Web 2.0. I think atproto’s ethos falls somewhere in the middle — community is mostly a “soft” primitive, and there’s only so many full-scale “copies” of some app as there are strong opinions+funding bundles that motivate their existence. So maybe not too many for large scale ones.
> Maybe we’re just ideologically misaligned here. I think every single little community hosting a copy of every single app is insane, and not where I’d like to end up
Well, it's where we used to be — and it solves most of the issues of the modern web. Forums, blogs, IRC, teamspeak, gaming servers, etc, it all used to work relatively well with that approach.
I don’t think the problem I want solved here is replicating forums, blogs, IRC, Teamspeak, or gaming servers. I want something a lot like Twitter but with some way to take my stuff and leave if an asshole takes control. I don’t want Mastodon, because from what I’ve seen of it when friends link me stuff from it it’s extremely clunky and slow. Plus, whenever I’ve gone to create an account I’ve been presented with a huge list of servers to chose from, many of which seem to be focused on a specific topic, which makes me think I need to pick which community I want to be tied to with minimal knowledge.
My immediate question while reading your post (as someone who doesn't know much about ATProto) was "but where is the box for Bluesky?".
You didn't draw a box for Mastodon either, but my understanding is that it'd encompass all the individual instance boxes in the Mastodon-brained diagram. I think if you were to draw a box for ATmosphere it'd encompass everything in your ATProto diagrams. But what about Bluesky, Eurosky, etc? Are they "apps" in your diagram? I don't think so because I'm pretty sure they also host users' data. Are they the dotted "hosting" boxes? What are these things even called? Apparently not "instances"; are they "services"? "Networks"? "Providers"? Something else?
You’re right that this is confusing!
Bluesky is two things. There’s “Bluesky hosting”, and there’s “Bluesky app”. Conceptually and on the network level they have nothing to do with each other. These are different pieces of software running on different stacks and they are agnostic of each other. Bluesky the company happens to run both because it’s kickstarting this whole thing. But you can swap hosting (I just did) while using Bluesky app, or you can keep Bluesky hosting but use other apps in addition (like Tangled) or instead of Bluesky (like Blacksky).
Eurosky is a hosting provider primarily. They happen to also develop an app (Mu Social) but afaik currently that’s just a skin for the Bluesky app (it talks to Bluesky app API). Nothing stops them from removing that dependency (like Blacksky did) though and making it an independent forked app though.
So the answer is — companies and organisations in Atmosphere often provide services for different roles in the system. Some do just hosting, some do apps, some do other kinds of network infrastructure that is used by many apps, and many do multiple things at once.
"but where are the instances?" is asking "if Bluesky the company disappeared or turned evil, would there be a Bluesky network that kept going?".
> 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.
> You can’t even accurately calculate things like post likes.
And maybe that's a good thing.
Perhaps, but that isn’t what users want.
Coming up with a new model for social media and also dictating what features are good and bad for users is going make user adoption a tough challenge.
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.
You can switch to the AppView from https://mu.social/ and you'll get editing working.
mu.social is a "client".
An "AppView" is the API server that most clients connect to that aggregates data from the network and serves it in a more useful way. mu.social still uses bluesky's AppView (api.bsky.app).
The name is confusing. I thought clients were appviews myself for a while.
I kind of started calling them all “apps” with true appviews being “independent apps”. I think sometimes it makes sense of think of this as an implementation detail. For example, Mu could actually switch to its own database if they do a bunch of technical work in the future. From the users’ perspective, it wouldn’t be noticeable.
> All of this goes away if we just do P2P social media.
This is the wrong way to see it. There is no "Best and correct" solution, only solutions with different trade-offs. ActivityPub/Mastodon/Federation makes sense in some cases, "pure" direct distributed P2P makes sense in some cases, one central server makes sense in some.
Bluesky/ATProto just made different trade-offs, for different use cases, some of which wouldn't have been possible without the architecture they ended up with, which sibling commentator expanded on exactly what.
Nostr is basically this.
It's a cool idea, in practice it kind of sucks as an experience.
It's been developed adjacent to the Bitcoin community and I can't say there's much going on besides spam.
Yeah, kind of a bummer. There are some cool ideas that have been implemented in nostr, but everything has that bitcoin/zap hussle.
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.)
> architecture astronauts
Not sure how I haven't heard this one before, but I'm stealing it. Salient descriptor.
Even has a wikipedia article https://en.wikipedia.org/wiki/Architecture_astronaut
Joel's post was the genesis https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Salient indeed!
> They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
Interesting. I'm an architect by title because my employer doesn't have the career path of a "senior specialist who really knows their stuff and wants to keep going at it". No. We have only two paths: either Manager (not interested in the slightest), or the almighty Architect. Every time I'm forced to architect something, that bit about the bottom line comes to my mind.
I'd say an architect is kind of the opposite from a specialist. The specialists cares about the stuff only they know. The architects care about the stuff everybody should know.
Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.
P2p networks either kill your phone battery or require you run a hosted instance somewhere, which cuts out about 99% of potential users.
This doesn't work for intermittently-online, battery-powered, CGNATed mobile devices, and that's what people are using in practice.
The Google / Apple walled gardens don't make it any easier, but even without them, the fundamental issues of battery life and intermittent connectivity don't disappear, walled gardens just force you to design around them instead of hiding your head in the sand and pretending they don't exist.
Secure Scuttlebutt was a fun implementation of this, but the project is all but dead with Staltz working for Bsky and the other maintainers moving on.
Perhaps ATProto vs. ActivityPub will been seen as the Fediverse's East-West Schism.
Instead of decrees over the "filioque" we get blog posts about the definition of "federation" where both parties talk past each other.
The good thing is bridgy fed/a new social exists, and you can trivially bridge atmosphere and fediverse today.
The east-west schism took way longer to allow some reconciliation :)
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.
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
Someone has to archive the data, right? Perhaps the complexity has been pushed to the AppViews?
If I read a post from a month ago, how will my client know how many likes it has or what the replies were? Without reverse links, someone has to look up in a database of all AT actions for likes/replies pointing to that post.
Contrast with the inbox/outbox forward/reverse linking model of activity pub.
AppViews already had to archive whatever data from the network they cared about. The change just means that an AppView won't be able to infinitely backfill from any relay, you either need to find a relay that archives all the data you want and backfill from that relay, or you'll need to backfill by querying pds's directly. Or you could just not backfill at all, your AppView can do whatever it wants to really. Clients always talk to an AppView to get information about the network, the AppView manages the building of reverse links, the relay doesn't care about the hydrated state of the network, its just a stream of events which occur on the atproto network.
> Relays are quite expensive to run
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
> their cost of operation is still something most people can afford: approximately $30/mo now.
Your definition of "most people" must be very different than the literal meaning.
How about, less than what many people pay for a tank of gas?
Most people won't do it, but they don't have to, and it's not a particularly expensive hobby.
In the US. How about in Kenya or Laos? Plenty of places where $30/month is closer to “median monthly income” than “an expense you’d barely notice”.
We don’t need everyone to run a relay to get to the point where there’s sufficient redundancy that no relay matters too much.
That applies to many other hobbies, not just running a relay; welcome to poverty. What's your point? Regular users don't have to run one.
I think that's unfair because most people won't run their own relays any time soon, but rather rely on a local enthusiast.
If $30 a month is too much for you, then you probably should be doing something other than trying to run a relay. It is just not a significant amount of money.
Most people reading this, then
$30 a month is a pretty massive costs for such a program. Why does it require such a beefy VPS, is it just the initial bootstrapping that requires such resources?
Because if you want to relay every single public event for every single user on the entire atproto network in real-time to many consuming apps and services… that's gonna cost something. Not that it costs a lot, but to expect what a relay does to be infinitely cheap is to not understand what it's doing or why it's doing it.
That's for a server that downloads and forwards all Bluesky traffic.
Not just all BSky traffic: all traffic from every ATProto service
"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
And I honestly think this is one of the fundamental problems with the push back towards protocols and decentralization. We're overestimating the bandwidth and capabilities of the average user and we haven't fixed the problems that pushed everyone towards centralization in the first place.
Take me, for instance. I am not only capable of running my own Mastodon or Atproto data server+relay -- I'm technically capable of writing my own ActivityPub or Atproto app.
But I'm currently sitting with accounts on bsky.app and mastodon.social -- the biggest most centralized "instances" (yes, I know, but it reasonably describes the problem). This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
And this is doubly and triply true for the average person who doesn't have the technical abilities I have.
As a result, both Mastodon and Bluesky are still practically centralized to a large degree. An overwhelming majority (more than 90% last I found data) of Bluesky users are hosted by bsky.app. Similarly on Mastodon, a large plurality of users (~20%) are on Mastodon.social. Mastodon's obviously doing better than Bluesky in this regard, but it also has about a quarter of the overall traction, and I'd honestly put that down to Bluesky's apparent centralization which makes it a lot easier for people to join and wrap their heads around it.
This isn't about "average user". Relays have nothing to do with using atproto as a user. They're about developers making new apps.
By "most people" it's implied we're talking about most people who want to run a web app in their spare time. Do you mean a different definition? If you want to run a web app (which is the only reason you'd want a relay) and you're able to pool with ten other developers who want to do the same, you can make the cost to $3/mo. Is that feasible? What do you normally pay for web app hosting?
And again, if you're a hobbyist developer, you'd just use a community relay that already exists and is free. I assume that, if you want to run your own, you have a specific reason to do so.
An average user does not need to run their own node for decentralization to work. It just needs to be cheap and easy enough for enough of technical users to run
I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.
- If you just want to use your domain name as a username, you set a DNS record.
- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)
- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.
- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.
- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)
>"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
I don't think that was a recommendation for people to do, but to demonstrate that it doesn't require much in the way of resources. That VM could probably host hundreds of people, since relays scale and de-dupe shared content.
If someone said that email or a personal website was inexpensive and could be hosted on a cheap VM, I don't think you'd make a comment like the above dismissing it as impractical: the idea is that if it's that cheap, then there are people that can host cheap/free (maybe ad supported) relays, similar to how cheap/free webmail exists today.
> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)
People have set up relays for like $15/month.
As far as I can tell, Relays[1] are the glue that makes ATProto work performantly. I think they're supposed to be content-agnostic — they just shuttle data through, reducing the number of services each AppView needs to be aware of.
As the blog mentions, the big improvement vs Mastodon is that Relays, AppViews and PDSes are separate services with their own distinct scaling demands. It's a rather beautiful solution to a system design problem.
[1] https://atproto.com/guides/glossary
Yeah, Relays are one way to do that. I've mostly skipped them because they're an invisible optimization and there are other strategies. E.g. many smaller apps today rely on Constellation (https://constellation.microcosm.blue/) instead of building their own database index, so they don't use a Relay at all.
They do remove content directly from relays. They claim they only remove content that is illegal to host, but I don't know how true that is, and there is always the risk it could change in the future.
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
I want the bsky org to be able to choose what content they host (and I think the internet would be a better place without section 230 protections allowing hosts to ignore the content they distribute); the promise as I understood it was that relays could be hot pluggable. If someone stopped carrying content (maybe it was illegal in /their/ region and not yours) you could failover to another relay.
However there is very little incentive to mirror any of the firehouse if someone else is doing it for free.
If a relay was silently dripping content how would you even know?
If that becomes a massive problem - host a relay with different moderation policy.
The scale-down floor for running an ATProto relay or appview is much, much higher than the floor for running a fediverse instance.
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.
Wouldn't you then not be able to see replies from anyone besides the dozen accounts your relay follows too? If I run a personal Mastodon instance and someone replies to one of my posts, their instance will send it directly to mine and I'll see it. My understanding of the ATProto architecture is that it doesn't support directed messaging like that.
The cost for consuming the firehose of the entire network is very low. So the actual cost that can blow up is storage and computation.
If you want to filter for events based on some heuristic (e.g. only from follows of server list), you can do that. You can then specialize that further. E.g. for ongoing threads that already pass your filter, you could add their IDs to an array, and accept all replies for those threads as well into your DB.
You already get a stream of everything so you can scale down what you write to DB to exactly the characteristics you need. Including keeping threads cohesive.
To refer back to the comment I was replying to: is that the sort of thing you could realistically run on a raspberry pi? At home?
Yeah! In fact some popular ecosystem services are (or at least have been) running on Raspberry Pi. See here: https://bsky.bad-example.com/can-atproto-scale-down/
Also the best algorithmic “For You” feed on the app runs off someone’s gaming computer at home
Since sync 1.1 last year, you can run a relay on a relatively small VPS
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.
Does this help clarify it?
> 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".
Great questions! The protocol does have suggested app-agnostic moderation primitives (see https://atproto.com/guides/labels, https://atproto.com/guides/creating-a-labeler). That's the basis of how Bluesky's own moderation works under the hood. There's also Bluesky-specific tools and APIs like Ozone (https://atproto.com/guides/using-ozone), but they build on top of those primitives.
Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
I had seen the mentions of labelers, though it hadn't been clear that that was something general beyond Bluesky-the-app, thank you. This would have been helpful to have in the article, alongside the mentions of defederation. When people are asking about instances, sometimes what they want to know is how you solve the same set of problems they care about, so here are the solutions to those problems, etc.
> There’s no “defederation” because there’s no analog of “community instances” that may fight with each other.
If Bluesky specifically wanted to just not have its user interact with some other entity in ATProto-land would they be able to?
My impression is that the answer to this is "yes", because people are signing up to Bluesky and relying on Bluesky to hold on to their posts etc.
Similar to how Email is all federated but in practice a bunch of people use email from one of a handful of large service providers who (in practice, not necessarily for nefarious reasons) do end up blacklisting certain email senders.
The RSS-reader example feels a bit different on the ground because for a given user, "store a list of websites you care about" is not a complicated endeavor.
For the "short-form social media with algorithmic timeline" usecase (which isn't all atproto is about, granted!) "users self-host a thing to scoop up enough of the world's posts to then make a local algorithmic timeline" doesn't... doesn't feel very feasible, right?
I guess the blogspot comparison is apt... but if "full" self-hosting requires a relay with quite some juice ($30 is "cheap" but... compared to a pile of files to host your own blog...), then in practice we're going to see a heavy amount of centralization anyways right?
A number of PDSes are already defederated from the bluesky relay and even more from the bluesky appview.
How is it any different than a centralized social media service then? Merely the fact that you can get a firehose from the website in a standard format? This was already the case with HTTP. The problem is that websites can leverage their power to make a locked-in ecosystem.
see https://www.youtube.com/watch?v=BxV14h0kFs0 twitter, etc once had a much more open API. so did reddit. This was just the first stage of their penetration strategy.
The decentralization is totally irrelevant due to the way it's implemented. The problem is that Apps are sticky, so app developers have undue power to control their users.
The "content hosts" "moderators" etc need to be completely cut out of the picture to be at the same level of censorship resistance as an RSS-shared blog. I can host a blog on my own computer, and you can subscribe to it without that many intermediaries.
Sure, you could say it’s a set of conventions on top of what you’re describing — that imo is sufficient to shift the incentive picture. It’s a firehose of typed JSON that’s canonically stored at URLs that survive hosting changes and can link to other JSON. It’s signed and verifiable and links to other JSON.
So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch.
I think that makes a big difference. Don’t you think?
New services don’t start with the same userbase because users don’t use protocols, they use apps. And for Bluesky that’s predominantly a single centralized app. If that demotes content from the “competitors” or even switches the protocol completely, you are stuffed. The apps are very much not equal.
99.8% on BlueSky PBC. If they turn off federation, it becomes centralised.
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 don’t know what you’re saying.
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 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.
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).
Well I think "can move later" makes all the difference because the initial choice doesn't matter to the individual user. It isn't even blocking. Most people don't know they're making that choice, and I think that's fine. In Mastodon, the choice is very high stakes.
Frontends and relays are far closer to “quacking like an instance.” That’s where your sysop’s power lives. The PDS itself isn’t very powerful - can’t meaningfully limit who you can talk to, for example.
ATproto sacrifices true decentralization for consistency, Mastodon and AP does the opposite, sacrifices true consistency for more accessible decentralization.
At least that's how I understand it, because running an AP node is much more accessible to regular selfhosters than running one of those content relays in AT.
So all you'll ever "decentralize" in AT is your own data, it's more about owning your data rather than collectively owning a part of the network.
And we've been over this many times before on HN.
This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).
With ActivityPub, because running an instance requires hosting the data, the application, and dealing with all the subsequent scaling challenges, you kinda have to choose between being taking on active ops responsibilities or tying yourself to someone else's instance (which will probably be one of the bigger, more centralized ones).
If you decide you don't like an instance you picked and decide to move (unless things have changed) you're kinda stuck needing to start fresh.
With AtProto, it's trivial to jump ship to a different application platform and continue using your same identity. Exporting your data from a platform and self-hosting is a bit of a UX challenge, but at least it's possible.
As an example, I recently started using Tangled for the first time and was able to login using my existing bsky-backed domain (h14h.com). No need to create a new account or pick a new username -- it was as if I were already there. Then getting set up w/ self-hosting my git repos on a VPS was an afternoon of work at most, and it's just some backend service chugging away that I almost never have to think about.
The worst that will ever happen is I see a banner message in tangled.org saying something like "your repo is out of date and may be compatible with the latest version of Tangled", which I can solve by simply rebuilding & redeploying a docker image w/ the latest versions.
Granted, AtProto is definitely harder to wrap your head around architecturally. But actually interfacing it with a user is much simpler, IMO.
> This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).
A good measure for decentralisation is: Can your community continue using the service if the rest of the world disappeared? Can you still federate with other communities that might still exist? What else needs to remain for the service to remain useful?
With mastodon, all of that is trivially answered. With AtProto, I'm either 100% reliant on bluesky, or I'd need to spend tenthousands of dollars a month minimum to self-host the relays and app view.
How is that trivially answered with Mastodon? And what does "the rest of the world disappearing" actually mean in your example?
Everything I'm seeing about hosting costs in the current day and age is that the full AtProto stack (PDS, Relay, AppView) is roughly in par with hosting an ActivityPub instance of equivalent size (if not a little cheaper).
And with AtProto, folks get to pick and choose what slice of the stack they wanna host, and opt-in to more of it gradually as they see fit. With ActivityPub, you are either opting in to hosting an entire instance, or fully reliant on someone else.
I'm open to the idea I'm misunderstanding some aspect of ActivityPub, given I've not really explored the hosting side of all that deeply.
Imagine bluesky (the company) and mastodon.social both disappear tomorrow.
My self-hosted mastodon server continues working, and can continue federating with e.g. chaos.social
With bluesky it's different.
If I am fully self-hosting the entire bluesky app, I need to spend ten thousands of dollars a month, but it'll keep working.
If I self-host my own app, it's cheap and keeps working, but I can only see content from my users in the best of times.
If I use bluesky's relays, it's cheap and shows everyone I follow, but it'll stop working if bluesky disappears.
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 agree, with the state of things as they are now.
I prefer AP for one reason, it's more accessible to the people. I would prefer to see small computer organisations with member fees, and donations, that run their own little node, instead of huge monolithic components.
That's why I never liked bsky, because it was too monolithic. I never liked the monolithic AP instances either. If we're going to decentralize, let's properly decentralize.
As soon as something becomes huge and monolithic, it's a red flag.
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.
Mastodon also has content relays!
But really, I actually would argue the opposite: ATproto is (or at least, wants to be) more decentralized.
In the ActivityPub world, identity, application, and hosting are intrinsically linked. If I want to use Lemmy, I can either register a second, permanently separate ActivityPub account on that Lemmy instance, or ONLY use Lemmy to the extent my Mastodon instance knows how to send messages that Lemmy understands. EVERY new ActivityPub app is a new set of interoperability concerns, because each app owns its own identity and hosting. There's no way for my self-hosted Mastodon instance to provide an identity to a Lemmy server and then for that Lemmy server to tell that instance to host content on my behalf.
That's the bare minimum you'd need to match ATProto, at least in the version being told to me by the ATProto people. No idea if any of it applies to actually-existing ATProto, in the same way that actually-existing ActivityPub can't interop the way ActivityPub supporters claim it can.
registering a separate account per instance is decentralisation - bluesky had a central account registry
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.
Well, the whole point of atproto is that the social graph also lives in the “blogs/RSS” part. The apps just index it.
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.
Google Reader had OPML exports and tried to export its social graph into Google+. On the other side of it many of the blogs in Google Reader had some version of FOAF or XFN to try to maintain social graphs through open standard "semantic web" good feelings.
A social graph is more than just data, it is trust, it is attention, and it is political goodwill. That's one of the most important lessons of the fall of Google Reader. It wasn't just that the technology was shutdown, but that it damaged communities when it shutdown. You can't capture communities that don't feel like they belong anymore, that no longer trust you because you closed their former town square.
I still don't see enough evidence if BlueSky itself shutdown that ATProto survives that shock culturally, even if it is built to do that technically. If Mastodon.Social, still the biggest instance, shutdown tomorrow a number of Mastodon instances wouldn't even notice and some of the ones that did notice would just as likely throw a party as lament the disappearance. That's a pretty big cultural difference, not a technical difference.
I agree with you but I think the technical capability intersects with politics here because anyone is able to make new stuff out of old data. That’s not the same as Google carrying it through to another Google product. I’m not aware of the FOAF/XFN stuff but it’s also different if that isn’t the entire graph perfectly preserved, easily queryable by everyone involved.
When developers feel empowered to revive products or fork them, I think that eventually seeps into communities. That it’s another way of doing things. It doesn’t happen overnight but this energy exists in the Atmosphere. Maybe loss of Bluesky is not survivable culturally at the moment, but maybe it will be in a few years as Atmosphere grows and matures.
Ominous, but accurate. Imagine RSS but you couldn't use a desktop or mobile RSS reader, but only Google Reader or a comparably scaled clone.
In exchange we have many excellent RSS Reader. Just as recently someone talked about NetNewsWire.
I like Newsblur. It has some social tools that remind me of Google Reader at its peak. I have friends that like The Older Reader. It has some social tools that remind me of Google Reader at its peak. Neither of those social spaces communicated between each other.
What we have is a "diaspora", what was once one larger community has moved on to a lot of smaller, more disparate spaces. That's not necessarily a bad thing, but a lot of trade offs were involved, a very large community feeling was lost, and a lot of intangibles were lost (friends with Gmail accounts that could easily follow and interact with us in Google Reader but are lost trying to navigate any other RSS Reader, for instance).
This blog does a great job of explaining the architecture. In practice though I’d thought the “problem” was that Bluesky (the corporation) runs the main app and hosts almost all of the user data.
So at the protocol level it’s decentralised, but in practice the system is still very centralised (in terms of who controls it).
Not saying this is necessarily Bluesky’s fault, but it’s how things have played out so far right?
The "problem" is that people are looking for problems. This "problem" isn't specific to Bluesky, ATProto, or anything else. Look at any organization: profit, non-profit, group of volunteers, etc. and you'll always find someone that folks have a problem with.
I'm not an investor and have no conflict of interest with Bluesky beyond being one of the earliest of users. I also understand the protocol, the company, the website within my own limitations.
The site (and app) works just fine. Folks are really focused on finding problems rather than coming up with bigger and better solutions.
Note: the majority of folks don't want an ad-hoc p2p solution like lemmy or mastodon. they want their content in one place, and they want to be able to hold that entity accountable. Because of this, p2p social networking will never take off. I've seen more drama surrounding both Lemmy and Mastodon than I have ever seen with twitter, reddit, facebook, etc. combined.
That's my 2 cents. Also, apparently my spouse feels the same way. So do my friends.
There are other apps, other user data hosting (including personal hosting), and other backend services.
It is decentralised in both theory and practice.
The only thing you could potentially say is that because Blue sky run the biggest parts, it's not decentralised at the community or mind share level, but that's changing.
Does really do a great job? It just says there are no “instances”, it doesn’t explain how the architecture circumvents all the troubles that it leads to such as auth, sync, discovery, etc.
An important distinction is that blogs have their own websites and they're not required to publish full articles in their RSS feed.
Bluesky doesn't normally work that way - everything in the PDS gets replicated. They are also encouraging people to put put full blog posts in the PDS for easy replication. So, anyone who wants to index it gets a copy and you have no control over what they do.
You don't have to do it that way, though. You can publish your blog on your own website and just publish links to it on Bluesky.
> So, anyone who wants to index it gets a copy and you have no control over what they do.
How does this differ from scrapers hitting the blog directly?
Web pages aren’t digitally signed, aren’t necessarily indexed by search engines, and there are ways to block bots with things like captchas. You also have much more control over the UI. 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.
How can people control the comments about their blog post on Hacker News? I think my example is closer to what happen in PDS and App View.
Aren't the vast majority of web pages nowadays signed? Almost nobody downloading and storing the content on websites will retain these signatures, but they exist and can be verified with enough information. IMO archive.org and archive.today should, to prove they haven't tampered with contents.
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.
The OP's article and replies in the comments here seem like someone who's comparing an idealised view of what Bluesky could be versus a cynical view of what Mastodon currently is. This troubles me because it overlooks the massive problems with Bluesky as it currently exists. It is hyper-centralised, much more so than Mastodon ever was. Virtually all users have their data stored by Bluesky PBC, aggregated by Bluesky PBC, access it through a website and app made by Bluesky PBC, and most crucially, are subject to the moderation decisions of Bluesky PBC at every turn. And I don't think it's a stretch to call Bluesky an “instance” here.
Now, sure, you can use a different instance for most of these services. And that instance can interoperate with Bluesky. But that's the case for Mastodon as well, and the real difference is the Fediverse has had to live with the painful compromises that come with the anarchy of the real world. I think Bluesky will discover its own version of defederation soon enough. I don't think “ah, but you technically theoretically can still interact with people even if you can't see them on your instance” is worth all that much.
Facebook is not just a "evolution of this concept". I would argue they, along with Twitter (currently know as X) and other similar service is completely different from blogs.
The main different is the designs Facebook has employed manipulated their users to adopt this "scroll down" method of reading. Each item of information is only displayed just a few seconds on user's screen, unless user stopped scrolling at the item they really interested in (and then maybe tap to open it).
That's not the same design used by blogs. Think of blogs as mini news sites, it encourages their readers to open the content in a full page to read it without interruptions. And, the readers has to calm their heats down to read long statements, this costs time and demands focus.
If you port the design used by blogs and apply it to display Facebook posts, that will be user-hostile, because user has to click each post only to read a potentially very short content.
The opposite is true too. You can't encourage user to "scroll down" a wall of long texts just to read the next wall of long texts, because that will be exhausting. You can't even create the anticipation that there's more stuff down, because that will just manipulates the user to keep scrolling down and skip.
That's why I think even you technically can aggregate blogs and social media in one app, you should probably be careful about it.
I've wondered for awhile why someone hasn't started the Blogger.com of ActivityPub/Mastodon: 1 "instance" per person, no weird complicated group dynamics, the service handles all the technical details, the user draws from the same cohort as the people who signed up for Blogger blogs in the early aughts.
If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage; like, I can see how Mastodon keeps chugging along no matter what companies get sold to who, but I don't see how ATProto survives the death of Bsky.
So every user would have to individually block all the nazi and child porn instances?
I don’t know what you mean by “instances” here. Leaflet (https://leaflet.pub) is one of those “blogger on atproto” things — is that what you mean?
Literally just Mastodon servers, like Hachyderm, except for a single user.
My bad, I misread your post as asking about single-user atproto "instances" (which confused me) but you said ActivityPub.
I still don't quite understand your comment.
>If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage
The advantage of atproto is that it's literally "the web". Every app can aggregate from entire network, there's no isolation by default. It reduces to the degenerate smallest case just the same — you can have a single-user app that simply displays content from your PDS. But you can also start aggregating things (e.g. comments left by other users, which are stored on their PDS's). The whole big idea of atproto is that every app is effectively a CMS for app-agnostic "model" web.
What is the concrete thing bothering you? AT is already in the IETF process. It's not some weird corporate thing.
You literally just set up a Mastodon server and only have a single user. That's what I do, and as far as I know it's the only solution.
A "lite" version of Mastodon that dispensed with all of the complexity involved with managing multiple accounts and was optimized for a single user might be nice but with a hosted account you're paying for data storage (which Mastodon seems horribly inefficient with) so in practice that extra complexity is moot.
Right, my point is, someone should stand up a service, like Blogger did for blogs, which were also trivial for people like us to set up and run on our own.
The thing there is it destroys the objection people have about having to find and fit in with a particular Mastodon server community.
It also makes Mastodon look more like the original blogosphere and less like Twitter, which is a good thing.
There are services that do exactly that. Masto.host is the one I use.
It is just an entire Mastodon instance with one account, though.
The same reason that they don't do that for Email. It's a lot more complicated for little obvious gain
The RSS comparison is misleading.
Atproto apps are not like an RSS reader that runs on the users' computers and connects directly to the sources of content.
Atproto apps are servers that control, filter and shape the content they serve to readers.
Atproto apps can censor, shadowban, show ads, algorithmize the feed into anything it wants. The user is powerless and the creator is a victim that can't do anything besides crying.
The fact that any person can host their data anywhere is completely meaningless since they have no way of distributing that data.
That’s the whole point of “apps”. Apps are opinionated points of view / prisms over the network. Of course they’re able to apply their own moderation decisions. That’s how the whole mainstream web works in general — you can’t even get an unmoderated app into App Stores.
The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.
That’s not really true. For one, you can have different AppViews which don’t do that. The feeds can be algorithmic however you the user want — multiple apps means you aren’t tied to what one central creator desires for those algorithms.
There's basically only one instance.
There's only one PLC directory.
There's very few full relays (edit: appviews), none that I'm aware of that don't mirror bluesky censorship/moderation decisions.
- There's no "instances" so I don't know what you mean by this.
- Re: PLC directory, indeed, there is only one of those. I think this is a legit point but it's worth considering the whole point of PLC directory is to be the single minimal stateless open source part that lifts identities out of apps and hostings. PLC governance and maintenance is being spun out into a Swiss organization (https://atproto.com/blog/plc-directory-org). Longer term the idea is for it to have a similar role to ICANN. Here's more on that: https://youtu.be/9z0z-Qu66yM?si=_8Dcw1M3VSKFGZhm&t=493
- Re: full Relays, they're easy/cheap to run, and you can run one yourself if you think the other ones are coordinating with Bluesky and don't trust their decisions. You don't need to depend on something else to do that.
> PLC governance and maintenance is being spun out into a Swiss organization (https://atproto.com/blog/plc-directory-org). Longer term the idea is for it to have a similar role to ICANN.
And since that sounds like a massive centralization problem, how do we have a dozen more of them with independent governance that aren't all controlled by either the same legal entity or by whoever has legal leverage to compel that entity?
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.
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.
Not necessarily – there are some activitypub instances without hostname, directly on IP addresses, and there are even some running in private DNS roots.
ATProto has both PLC and ICANN
ICANN is a severe risk btw. Current new protocols should be designed to avoid DNS wherever possible.
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.
There are many relays, here's a list of 13 but it's not comprehensive: https://tangled.org/firehose.club/community-firehose-list/bl...
Bluesky's moderation actions are generally implemented as moderation labels which take effect at the AppView level. Sometimes they'll take down someone's PDS or censor from their relays, but I don't believe third-party relays are aware of those relay takedowns at all.
You're right, I was probably confusing appviews with relays.
Most decentralized systems I can think of tend to follow a power law distribution (roughly) where one or a few platforms dominate. In the fediverse that's mastodon.social (or maybe Threads), in email that's Gmail, in AP that's Bluesky. I'm not sure this is unique to the AT protocol?
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.
This is the real strength of ActivityPub compared to ATProto. I follow a lot of accounts on mastodon, and only a handful of them are on mastodon.social. Globally though looks like 1/4 of the accounts are there.
If the instance goes down, the network stays up and continues to work, minus only the accounts on mastodon.social. This is not the case on bluesky afaik. They got DDosed a few months ago and the whole network was down because of it. https://news.ycombinator.com/item?id=47802330
In ATProto there aren't 'instances', and its technically 'decentralized' but theres really only bluesky.
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 wonder why were relays mentioned only mentioned in passing and there was no elaboration on how they interact with the rest of the network. Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?
Author here!
I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.
An app can work without a Relay (like https://reddwarf.app/ does). There are caches like Constellation (https://constellation.microcosm.blue/) that you can just query directly.
A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)
Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.
> Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?
I wonder why you are vagueposting here instead of stating your position firmly. Maybe because you are afraid to be shown wrong, but who knows ?
I just searched up Relay and I guess Relay is like Feeder in the analogy? I don't need it? And if I want it I choose one (many?) or run my own.
You need a relay unless you want to have all the same NxM scaling problems as Mastodon.
Not really, considering there aren't that many app servers. Each PDS sends out its events, those events are picked up by whoever wants them, mostly relays but some apps might directly subscribe. The more apps in play, the more connections, but it is not the case that for every new PDS, every other PDS now has to open an additional connection. It scales with the amounts of apps, not PDSs.
Mostly because having a big centralized firehose relay is less decentralized than people want to admit.
That's not true.
It's not centralized in any way that matters. The Relay Bluesky uses is open source, you can run your own for $30/month if you really insist on doing that, it's trivial to pool between multiple apps if you want to lower costs, and there are already a few independent ones you can just use directly now, for example:
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Fatproto.afri...
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh...
Why is that a problem if you can host relay for $50 per month as TFA mentions?
I really want AT to succeed.
It seems to be the nexus of federation + https://signal.org/blog/the-ecosystem-is-moving/
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.
>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.
Okay, but that's always the case when you get banned from a service. The difference here is that it's possible to build a competing service with different moderation decisions being a lens over the same data.
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.
That goes to the heart of the issue. Bluesky's dependence on VC money and for-profit structure means it has a conflict of interest with long-term survival and independence of the protocol. But that might be fixable.
The mitigation is of course more companies and open source projects getting involved. As far as I understand it, the protocol is pretty well designed, and there is a bunch of open source out there already. It just needs more people to get involved.
But the article pointing out that you can migrate your Bluesky account to a thing called Eurosky was actually news to me. As is the existence of non Bluesky owned applications on top of atproto. I might give those a try actually. It seems a lot has happened since I last looked at this stuff a few years ago.
That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well. The more independent atproto software projects are out there, the harder it is for Bluesky to make breaking changes. That naturally pushes for some independent governance. I wouldn't be surprised to see that happen over time. But worst case, there could be some kind of fork/split of the network.
It would be interesting to see some attempt to bridge with other networks. A mastodon / bsky hybrid. Why make people choose? Despite X's demise, it's still X versus everything else. There's also Meta's Threads and a few others. The whole "not X" space fragments users over multiple networks that sort of could federate if they would but they really aren't. I think Threads is nominally mastodon compatible at least but actually federating is a bit frowned upon by Mastodon users.
And while we are "at" it, why not support email as well? Which is the og. federated communication network with essentially all internet users as active users. It's not perfect, but nothing better ever managed to replace it.
Separating identity from protocol is a good design choice. Cross protocol federation is a logical next step. It's all about receiving content from people, not about staying in walled gardens that belong to share holders.
>It seems a lot has happened since I last looked at this stuff a few years ago.
Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog
>That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well.
The core part of the protocol is literally going through the IETF process now: https://atproto.com/blog/taking-at-to-the-ietf. It's happening.
Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.
Never rely a service just because they _hope_ to one day be less decentralised.
It doesn’t fully resolve your concerns, but I do want to highlight that atproto now has an IETF working group to home its spec development
"Seems to have worked OK for email"
THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.
ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."
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.
*: Not an .xyz, has proper SPF and DKIM records
Nobody asks _how_ are all the Bluesky instances :(
Missing from this is Nostr, which is very similar to Atoroto
ATProto is good at what it was originally designed for: decentralizing Twitter. It allows a gradual introduction to the network and ensuring you have control over it at the same time.
When a user decides to jump ship from mastodon.social run by Mastodon gGmbH to another server, they are using a similar but different service. It has different moderators, different emotes, different themes, different federation list, etc. They all have a different flavour, and, for better or worse, they come in a single package.
When a user decides to jump ship from bsky.social run by Bluesky Social, PBC, first of all... what does that even mean? Do you want an alternative storage (PDS) for your data that will still be read by Bluesky the app and Bluesky the relay? Do you want a different "service" (what @ calls AppView) which is then not Bluesky? Do you want a different handle other than @[username].bsky.social? If that's the case, you don't even need to faff around with alternative PDSes or AppViews, you can just slap your domain on it!
Mastodon invites users to federate by giving it a character. Bluesky slices and dices it to a point where the only reason you would bother considering decentralisation is for ideological reasons. And to that point, Bluesky has consistently prioritised building their own service up rather than decentralising. You still can't export photos and videos you've uploaded (through their AppView). Until some time ago you weren't able to return to using Bluesky's PDS once you've moved away. And of course, because ATProto operates out in the open, features such as bookmarks that are supposed to be private doesn't even go through the ATmosphere. (I'd love to know if these are exported but I don't know of a way to open their ".car" file which is neither a plaintext nor a zip file.)
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.
Right, which is why my article has this paragraph:
>I say “Mastodon” here because if I say “ActivityPub” instead, a crowd of people will show up and say that actually what I’m describing is how Mastodon chose to implement ActivityPub. Whereas ActivityPub by itself does not really specify how to actually use it in practice.
I understand there's other ways to use AP, but when people say "where are Bluesky instances" they are specifically comparing AT to Mastodon's AP topology.
There are multiple Bluesky AppViews, Blacksky has a totally independent one. And there are multiple relays, each capable of serving a firehose.
You can have your own AppView and Firehose. They're just relatively expensive to run versus a PDS.
Running your own firehose is not expensive, fwiw, it's $30/mo. If I were making a "serious" app I'd probably do that. Otherwise, relying on community-maintained ones seems fine.
Running an AppView for your own app is not expensive at all. It can be as cheap as you want. It's only expensive if you want to store gigabytes of Bluesky posts and serve them to millions of users — i.e. if you want to build the full Bluesky AppView. But why would you want to build a Bluesky AppView? That's part of what I'm alluding to in my article — atproto isn't "for Bluesky". You can build any social app.
> But why would you want to build
The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.
I don't understand how running your own Relay is related to competing with Bluesky. A Relay is just a dumb websocket broadcaster. Yes, you can absolutely run one on your own if you don't want to rely on any of the existing ones. I don't think this has to do with competition.
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.
No tools meaningfully "default" to it — it's something you set up at the app level. And no, it's not hard to change, it's literally a single string constant that you put yourself into the code. If I were making a serious app, I'd likely run one myself for peace of mind. It's not difficult, you just spin up the Docker instance with it.
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.
I have a different article that goes into this here: https://overreacted.io/open-social/#open-social
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).
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/
Thanks! Your name makes me think of a funner pre-LLM time when Elm and Redux was new and cool. Great explainer!
Kind of a similar article, but in French : https://bonpote.com/bluesky-enfin-une-vraie-alternative-a-tw...
This reminds me of the early arguments about RSS.
TL;DR: people complaining why there aren't bluesky instances are misunderstanding atproto. There are no "instances" like in Mastodon, atproto is different, it uses many "hostings". Except those hostings are just instances of the hosting software. And there in fact aren't that many.
But you're just Mastodon-brained, you don't get it!
> Are people migrating to alternative hosting?
Yes, are they? Where are the alternative hosting that do the same thing as Bluesky?
Here's a list of active alternative hosts: https://blue.mackuba.eu/directory/pdses
As I mentioned in the article, I literally migrated to https://eurosky.tech/accounts/ yesterday.
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.
So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
What kind of censor?
Whoever operates hosting can decide to ban someone from hosting. This isn't different from how Cloudflare would ban you for hosting something illegal.
Whoever operates an app can decided to ban someone from that app. This isn't different from how a forum moderator can ban you for something they don't like.
Whoever operates services in the middle may decide to ban someone for network spam/abuse, same as cloud services may do if you abuse their limits.
You can always try to host your stuff elsewhere, and you can always access the same network from another app whose decisions you prefer.
So it's basically same as usual on the internet, but each role is separate, and you can mix and match what works for you.
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.
> So all the censor needs to do is cut off one host? And then you upload everything to different host and connect that?
Which host?
If you're curious about atproto and feel like a n00b about it, this is a great place to start.
I read the post a few times, but I still have some questions that I feel weren't answered, probably because I lack the deep protocol knowledge. For context I run a 'single-user' Mastodon instance, and I don't really see how that is any different than either the blog or what ATProto offers.
What I'm most confused about is that an 'instance' has just shifted elsewhere. Sure, with AP you have to choose an instance, or just go with the default mastodon.social. AT doesn't seem to have instances but, you have to choose a host, and I suppose there's probably a Bluesky default host. I can't really see how that is any different. You probably could self-host an AT host as much as you can self host an AP instance for yourself (I run mine on a $6/month VPS).
The second point I don't quite get is that these apps don't seem to solve the same issues that instances do, and I believe this is the part where I'm lacking AT Protocol knowledge. If, in running my own host, I need to have software that handles access control, authentication, follows, etc, then I'm running an instance, even if it's called something else. If a host stores only data, then at some other place there is software that handles follows, access control, etc; then that software is equivalent to an instance, even if it's called something else.
When people ask where the AT instances are, I think about it like this: with mastodon (or any other AP app) I control not only my data, but the code that handles it. With ATProto what it seems like to me is that I can control where my data is, but not the code that handles it (considering the main criticism that you can't run bluesky 'instances', even if instances are called something else). That's why I think 'There Are No Instances in atproto' doesn't convice me. There might not be something called instance or it might be broken down in different components, but there is at least something equivalent. If you have a million different hosts but this data is handled by a single component hosted by someone, then you can't really say it's decentralized.
Sure, there are technical differences between both protocols, but from a user perspective without protocol knowledge, it doesn't seem any different from the outside. You download the app and use the default host/instance and if you don't want to be on the default one you have to get technical regardless of which protocol you chose.
One bit of feedback is that the somewhat 'snarky' comments directed at ActivityPub might put off the target audience of the post, that are precisely the people who ask where the instances are. But all in all, I feel the article did a good job of explaining the differences (besides the few points I mentioned earlier) and clarifying that ATProtocol has a clear separation between the data and the presentation of the data. While it's something that AP can do (my instance works with mastodon, with pixelfed, and other 'Apps' and my data is in a machine I control), it's not the default and data tends to be tightly coupled with the big instances.
My uninformed(about this particular enterprise) but educated guess: if tomorrow VC funding evaporates all this network cease to exists. I guess based on feely that 80% of all of these Relays, PDS, Apps including, Bsky are all from few if not one company, meaning centralized behind the curtain, but decentralized evangelism. It is very possible I am completely wrong, and so be it.
So all the content servers under one big auth infra; you could post anything on relays and apps, doesn't matter because your account is banned and nobody has the key to fetch those invalid data from relays.
I mean, that's how it went, after all. BS/AT is a fine replacement for twitpic-era Twitter, but it's not a locked-open decentralized social media.
I don't know what your first sentence says at all. This doesn't seem related to atproto.
The AT Protocol has a federated network architecture, meaning that account data is stored on host servers, as opposed to a peer-to-peer model between end devices. Federation was chosen to ensure the network is convenient to use and reliably available. Repository data is synchronized between servers over standard web technologies (HTTP and WebSockets).
https://atproto.com/guides/overview
great job explaining the concept!
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.
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?
> Yes and I find it rather egregious that you can pay (a lot) to self-host a full stack [...]
I wrote this other comment that I think does well to address this misconception: https://news.ycombinator.com/item?id=48601998
> Many options of places to go in the Fediverse, with a wide spread of different ideologies and approaches to moderation.
And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.
> 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.
Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.
> 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.
True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!
> 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?
There is nothing in the protocol enforcing this and this expectation has been broken in the past.
https://github.com/tuskyapp/Tusky/issues/2224
This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!
---
I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.
> I wrote this other comment that I think does well to address this misconception: https://news.ycombinator.com/item?id=48601998
OK, but that raises a question. Can I do that right now? If so, I don't understand why more people are doing this. When I looked into this I definitely didn't see anything like this.
> And an account tied to exactly one of them, that is a pain to migrate if it's even possible with the ActivityPub application you use. This causes decision paralysis and dissuades most people from even considering joining.
I like the concept of W3C DIDs, but it's a little soured for me that there was no real solution to the PLC DID problem. It is, quite literally, the exact opposite of being decentralized. (IIRC they do support one of the other DID methods, but it's not default, and I couldn't figure out how.)
Which seems like a common theme. You can absolutely fix the downsides of the Fediverse, it just requires you to reduce how decentralized the network is :)
> Within what is effectively a rounding error, everyone that uses ActivityPub uses Threads. Blacksky is definitely a larger percentage of the ATProto network than mastodon.social is of the ActivityPub network.
While this is technically correct, Threads is not widely considered an instance in the Fediverse and is missing in "instance lists". Threads is less like a part of the Fediverse and more like a centralized social media service service that supports interoperability with ActivityPub.
> True! Just like if there were hypothetically only two ATProto applications, that would not be very interesting. I think I've used four or five ATProto applications with my identity? Pretty cool stuff!
This is cool but not relevant. I'm more specifically talking about Bluesky vs the Fediverse here, when referring to the protocols. Obviously there are also uses of ActivityPub that are not Mastodon/Misskey as well.
I haven't seen another ATProto application that I found interesting enough to try yet.
> There is nothing in the protocol enforcing this and this expectation has been broken in the past.
> https://github.com/tuskyapp/Tusky/issues/2224
I never suggested it was literally impossible for someone to do it... but the concept of a "Mastodon" app is inherently agnostic to the instance in a way that Bluesky's apps are not.
> This is in addition to the fact that "clients" in ActivityPub extend to the monolithic instance itself, and therefore is also broken by the very "defederation" you already mentioned!
Sure. I'm suggesting you can't actually have decentralization without the possibility of all of ActivityPub's downsides. You can't use technical means to fix the social problems with decentralization; you can only defacto centralize things.
> I am very familiar with ActivityPub. I don't hate it. I ran multiple instances for years (one for my friends, and one for my family). ATProto is simply more flexible (allows applications to scale up to provide an experience that one would expect coming from centralized applications) and easier for non-technical people to use. And it's decentralized, which is awesome.
ATProto is decentralized, at least to some extent.
Bluesky isn't really, though.
You're refusing to look at the ATmosphere network and instead compare Bluesky to the Fediverse. I can instead compare mastoson.social to the ATmosphere and draw the inverse conclusions. What's the point?
Uhhh, I'm comparing Bluesky to the Fediverse because that's the main applications of ActivityPub and ATProto? I don't care about the broader ATmosphere.
How is comparing Mastodon/the Fediverse and Bluesky unfair? Are you kind of admitting that Bluesky isn't actually practically decentralized by suggesting the AP analog of Bluesky is the largest Mastodon instance rather than the federation of them? This seems to contradict what you and much of the marketing around Bluesky says.
Where do I login to the Fediverse? It's not an application. It's a network of applications.
Where do I login to ATProto. It's not an application. It's a network of applications.
Where do I login to Bluesky? https://bsky.app
Where do I login to Mastodon.social? https://mastodon.social
People use apps, not networks of apps. Saying you don't care about the broader ATmosphere is exactly the same as saying you don't care about the broader Fediverse. That's fine, but then let's compare apps to apps instead of an app to a network. How does bsky.app compare against mastodon.social? (Actually let's not do that, because comparing a single app in a decentralized network to a single app in another decentralized network is pretty boring).
> Are you kind of admitting that Bluesky isn't actually practically decentralized
The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.
I really dislike you trying to turn this around on me like I'm the one spewing out gotchas. I'm not. You are. You did it with Threads and now you're doing it again with this nonsense.
I'm comparing two supposedly decentralized microblogging platforms, Bluesky and Mastodon (and compatible microblogging software.)
The things in your post don't hold up. For example, people log into apps. OK. So when I log into my email account using Thunderbird, that's decentralized. Right? Literally I am using a client to connect to some IMAP+SMTP server. Couldn't be more decentralized.
So now let's say I log into gmail.com. That's still email. Is email still decentralized with the existence of gmail? Well, it is less so than it maybe should be, but absolutely! Because I actually use Fastmail. That's what a federated network looks like.
When I log into Matrix, I still use Element regardless of homeserver. I can use any instance of Element, or install it to my machine. But still, it's Element. That's what a federated network looks like.
Not all decentralized things are federated. Some of them are, for example, peer to peer, and many other architectures.
I am ignoring the broader ATmosphere because it is not part of Bluesky the microblogging network. There are also plenty of ActivityPub applications that are not Mastodon-compatible microblogging networks, and I'm not talking about those either. I'm not talking about, for example, the network of Peertube instances that are also using ActivityPub.
I fully admit that I am not an ATProto expert, but if you're not running a Bluesky compatible AppView that speaks the Bluesky schemas, you are not participating in Bluesky, which is what I am talking about specifically.
I have used the terms "ATproto" and "ActivityPub" only in the context of Bluesky/compatible and Mastodon/compatible. That is it. If you wanted to argue about something else, it is not me pulling a gotcha on you to refuse. I just simply don't care, and you are not taking the hint. It's my damn comment thread, I know what my intended scope was. I know, too, you must know that Bluesky itself is supposed to be meaningfully decentralized, such that you can indeed run your own entire appview stack and still be a part of Bluesky, so you must understand that what I am doing is inherently an apples to apples comparison.
Yet when I log into Bluesky using a Bluesky app, what I get is the Bluesky appview and Bluesky moderation service. This is because Bluesky is substantially more centralized than the Fediverse. You can kick. You can scream. It doesn't matter. Bluesky. Is. Centralized.
> The data is meaningfully decentralized (more so than any AP app). The user identity is meaningfully decentralized (more so than any AP app). Moderation is meaningfully decentralized (similarly to AP apps). Independently developed applications are meaningfully interoperable (more so than most AP apps, especially leveraging DIDs). People can and do run their own AT infrastructure all the time. Ask questions instead of trying to pin people with gotchas based on incorrect assumptions.
With all due respect, to the extent that there is any, no thank you.
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.
> Blacksky is literally the only such example of alternative infrastructure that I know of
That doesn't mean other places aren't doing so. As an example - here's a list of all the relays that mirror the ATProto network: https://atproto.at/relays
There's 16 relays by my account, of varying sizes. Of course, you don't have to query a relay - you can look at the Personal Data Servers (PDSes) directly.
Speaking of - there are just over 3000 PDSes: https://blue.mackuba.eu/directory/pdses
Each of these PDSes hosts one or more accounts, and you can self-host your PDS to truly own your data up and down the stack.
There's also oodles of different applications, of which Bluesky is just one. There's:
* Germ (encrypted DMs, Signal competitor)
* Leaflet (blogs, Substack/Medium competitor)
* Semble (link collection/sharing)
* BeaconBits (location-based social media, like FourSquare)
* SkyReader (Google Reader)
* Keytrace (cryptographic identity proofs)
* Smoke Signal (social events)
* Teal.fm (Last.fm)
* Goals.garden (goal/habit tracking/accountability)
* Tangled (GitHub)
* Sifa (LinkedIn)
* BookHive (Goodreads)
* Streamplace (Twitch)
* Spark (Instagram)
* Grain (also Instagram)
* Popfeed (Trakt)
* And more, like the TikTok clone I can't remember the name of, some more blogging platforms, a (fairly dead) Hackernews clone, some games, etc.
That isn't even mentioning all the Bluesky clones like Blacksky, Eurosky, Northsky, and W.
Each of these shares the same account - the account on your PDS, which you can self-host on any computer with an internet connection. I run mine alongside my smarthome server. Because they share an account, they interop - I can subscribe to a blog on Leaflet and have it show up in my Bluesky feed.
These services can fetch data from your PDS directly, or they can look at the Relay and get the full view of the network - but frequently, they don't need to.
Bluesky went down a couple months ago and many of these services were all perfectly usable, because they used the protocol but not any infra provided by Bluesky itself. The people who couldn't access the network were the ones who relied on Bluesky to host their accounts - which is a majority of the network, sure, but in the same way that Mastodon.social is a good chunk of Mastodon's network. I was able to use Blacksky to post onto Bluesky while Bluesky was down, because I was self-hosted.
Now both Eurosky and W have launched; Eurosky is aiming to be fully independent this summer and I _think_ that W already is? W's a bit more closed-off than most of the other projects I named, going directly after Twitter-as-it-is-now and not Twitter-as-it-was (hence why they chose W to compete with X).
Relays are now cheap to run, but they don't enable you to actually be independent. You would need a proper AppView for that. Eurosky is actually not independent at this point.
Yes, and this is exactly why ATProto is worse and more dangerous. Instances are safer. precisely because they are more genuinely decentralized.
The ability to forever tie your stuff to a person, strongly, is exactly what the surveillance state would want.
Mastodon's model gives you plausible deniability. It's safer.
I'd say atproto gives you a clear sense of what's tied to each of your identities — you can go and explore your repo in a browser. There's nothing to say your identity has to be "tied to a person" anymore than your Mastodon account on some server is "tied to a person". It's true atproto has a "scraping is the default, so expect it" vibe, whereas maybe you're arguing Mastodon allows security by obscurity?
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.
Nothing is stopping you from making more identities, though?
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.
Semi related post on why the moderation of federated Mastodon instances is a problem: https://blog.raed.dev/posts/mastodon_moderation
To be fair, from 2022. I would argue that moderation in Fedi is holding together reasonably well. There are a few popular instances that lots of people think are overly aggressive/purist in their moderation policies, but the people using them seem to like what they're getting.
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.
was that lemmy.world? As you have discovered, some instances are full of drama. Such is the nature of decentralisation. If you don't have some parts of the network full of drama there's probably a central entity suppressing it.
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).
Every time I see a post praising ATProto on HN I cannot shake the feeling that this might be the product of a concerted (and VC-backed) marketing effort.
ATProto is "decentr-washing" as far as I'm concerned. Even if you self-host as much as possible, if Bluesky's relay declines to crawl your PDS, or its AppView declines to index/serve your records, then to essentially the entire audience you simply don't exist. did:plc controlled by a Swiss Verein, as if this could be a reason to drop all self-sovereignty worries! Credible exit was actually always working well on ActivityPub already, and if you self-host your instance you probably won't even need it anyway. Regardless, there is FEP-ef61 now, so I genuinely don't understand why to prefer ATProto over ActivityPub, even in the foreseeable future.
Let's not even talk about Nostr, that natively solves all the issues that ATProto seems to care about. Nostr is IMHO a much superior technology, unfortunately plagued by ecosystem/people and Bitcoin-dictated technical choices (BIP-340 keypairs, brrr).
We could develop an all in one stack that handle relay, AppView and iOS / Andriod / Web apps to serve small communities and have the Mastodon instance vibe, except one identity could appear on different instances at the same time. It doesn't exist yet, but it's possible.