My article was an attempt to dig at this specific misunderstanding by comparing it to "But where are Google Reader instances?" which I think illustrates its absurdity. I genuinely do think that the two pictures I provide close to the end clear this up in a way a lot of early atproto/ActivityPub discussions completely gloss over.
Re: Relays, I wrote here on why I didn't include them: https://news.ycombinator.com/item?id=48600963. They're kind of incidental perf optimizations rather than essential to the model. In the post, I wanted to focus on the model.
What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.
If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.
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.
Of course depends on the context, but in a lot of discussions about ATProto, ActivityPub, Mastodon and nearby areas, people talk about "instances" as in "ActivityPub instances that host my data and my profile uses its URL as a 'name'". The blog post is specifically for that context I think.
It's less about trying to hide around the issue, and more reframing how you see the concepts, as people start to associate words with concepts and structures. So when people talk about "decentralized social media", lots of people think about ActivityPub, which typically (always?) has a kind of federated architecture, and the instance is one of those nodes in the network. When these people see ATProto, instinctively (and perhaps rightly so) they literally ask "But why is there only one Bluesky instance that people join?" as those concepts map close to what they know.
Overall I think the post is a good and useful addition to the discourse, with perhaps not a completely novel perspective, but posted publicly for future reference when this inevitably gets asks again sometime in the future, specifically for the people who have these previous associations already formed in their head.
Swarms of content.
Cryptographic identities and content signing/attribution.
Cryptographic hashes for content uniqueness/immutability.
Immutability in general.
Ephemerality (content lives as long as some node cares to retain it, otherwise it gets forgotten).
Concrete but extensible ontology for core concepts.
You don't need login. You don't need to agree on a common platform. 3rd party tools and extensions can filter content, provide trust graphs, interest graphs, etc.
You can just slurp up and score whatever might interest you. Your agent or algorithm might do pre-filtering against your preferred heuristics to downsample to relevancy.
You could write any client for this in any shape or form. Completely different look and feel for different people and interests / focuses.
Atproto is an attempt to engage with the problem space in a way that hits the baseline UX of Web 2.0 apps.
But it’s worth noting atproto designers come partially from P2P lineage. Some worked on Scuttlebutt, IPFS, and others.
And maybe that's a good thing.
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.
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.
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.
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.
(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)
Not sure how I haven't heard this one before, but I'm stealing it. Salient descriptor.
Joel's post was the genesis https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Salient indeed!
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.
Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.
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.
Instead of decrees over the "filioque" we get blog posts about the definition of "federation" where both parties talk past each other.
The east-west schism took way longer to allow some reconciliation :)