What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.
If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.
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.
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 :-).
No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.
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.
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?
They could rely on some relays to build their AppViews. The flexibility is already there.
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.
You're constantly looking at it from the wrong perspective. I don't care about the instance I'm on banning me because I am the one that hosts my instance.
What I care about is that I am able to connect with any of my friends without the data going through any central arbiter that can decide what we get to see or not.
And on mastodon, if one instance defederates from me, pretty much everyone else will still be able to interact with me anyway, it's not the end.
> 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).
This isn't as different as you make it sound. Most people on AT Proto are using Bluesky, so "getting banned" is fundamentally the same for them as getting banned from a Mastodon instance. Conversely, you can just run your own Mastodon instance and the only thing you'd have to worry about is defederation (an "appview ban").
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.
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.
- 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'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.
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.
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?
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.
Even if it’s not open source, anyone who wants to write the code can still get it back up with all public data intact.
I think it’s a substantial difference with “takes the whole thing down”. Can we acknowledge that?
>"But where are all the Bluesky instances?"
I agree that it doesn't mean "atproto went down", and I don't mean to imply that. but "bluesky went down" is completely accurate, and bluesky is the one claiming to be decentralized due to using atproto. there are no other instances in bluesky's network, only partial ones (blacksky, last I heard they were still working on a major piece?), hence the "no it's not" responses. and that's also how they're directly encouraging people conflating the two.
All I’m saying is that if a developer forever takes down some atproto app, another developer can put up a new app that shows the old app’s data because the data is actually inside the users’ repositories. This is similar to how if Microsoft ever discontinued Word, you could still open Word documents in Google Docs. Does that make sense?
Re: Blacksky, they do fully run on their own infra now. So it doesn’t depend on Bluesky’s database.
Blacksky finishing their full forking does finally give them a much stronger leg to stand on for "bluesky is decentralized", though.
PDSes are great and I really wish Mastodon would support something similar. Mastodon's lack of account portability / data ownership / lightweight hosting is a massive issue.
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.
I'm kinda hoping someone sets up a rainbowsky or something for us in the LGBT community. Now that I would join.
You can have an account on Northsky and use it with Blacksky's appview!
I'll definitely try it out!
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).
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.
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.)
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.
> 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.
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.
> 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.
As you're already self-hosting ATproto anyway, why not self-host a mastodon instance as well?
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.