Item — HN Reader

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.

5 comments

From my perspective, I care about the centralization/decentralization aspect a lot, and if I'm coming into the discussion with a much better understanding of the Mastodon side then _of course_ I'm going to ask about the instances--that's the vocabulary I'm going to use to try to probe for flaws and gaps. It's not necessarily that it's the instances specifically I care about, or that I'm somehow technically misguided.

What I hoped to read in the article is how we approach topics like centralization, censorship, moderation, data ownership--and with a technical lens. But I feel like all I got was "here's why instances are the wrong vocabulary" without substantively talking about the part I personally care about and want to marry the technical understanding with. Maybe I just read too shallowly and need to sit with it.

I see! That's a huge topic by itself since you're raising a lot of questions. Maybe this could be a different article. My aim with this one was just to clarify the network topology because it is a prerequisite to having the other discussion, and too often that prerequisite is not there.

If you ask a list of specific questions, that would help a lot. I might be able to write something or reply inline here.

I'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.

Does Blacksky have its own DID system, are they using did:web, or do they rely on blue sky’s did:plc? iiuc did:plc is what allows people to change their handle/use custom domains with the same account, but only Bluesky offers or can run did:plc, everyone else who wants to run their own full stack themselves is relegated to did:web which essentially has the same restrictions as ActivityPub where your account is tied to the domain hosting the DID.

> only Bluesky offers or can run did:plc

PLC is set up in a way where the database is fully visible and exportable. any censorship would show up in logs. if bluesky ever pulls it off at least part the community will stop trusting them, start their own server and patch apps to use the new domain. i know its not that easy in practice but its possible because everything is open source.

> ...your account is tied to the domain hosting the DID

thats nothing like the activitypub model. the atproto equivalent of an instance is your PDS which is something most users dont self host. did:web is not bound to a PDS, it uses a domain you own and a static https server you probably already have to host one file in `.well-known`. the risk of losing your account is much lower because someone would have to steal your domain or vps. theres no admin who can take it away.

yeah yeah “PLC is mirrorable” but can I run my own federated did:plc service at this moment for my own community? As far as I understand, I cannot and am limited to did:web and all the associated drawbacks, or having users sign up with Bluesky’s PLC directory to actually allow for the username portability ATproto promises.

> 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?

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 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.

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.

Spark, pckt (and leaflet, tangled) etc aren't using atproto as a compatibility layer: they're fully-fledged apps built on the network.

Right, but I think a typical Bluesky user never sees data from there in their feeds?

Don't get me wrong, I think it's pretty cool that you can run all these different apps and have them store their data on their own PDSes. And theoretically it's possible for everyone in my Bluesky feed to be on their own PDS and use different apps. But the question from a Mastodon point of view is: is that the case in practice, and if not, how likely is it that there will ever be a significant portion of non-Bluesky posts in an average microblog feed, on atproto?

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.

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.

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.

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 not only for Black people. They’re only reserving the blacksky.social domain handles for them, everyone else who wants to have a Blacksky account can use the myatproto.social domain.

https://northskysocial.com/ might work for you!

You can have an account on Northsky and use it with Blacksky's appview!

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?"

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, 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).

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?".