6 ms·

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

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

JasonSage 4mo ago
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.
- danabramov 4mo ago
  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.
  - JasonSage 4mo ago
    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.
  - Vinnl 4mo ago
    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.
    - ascorbic 4mo ago
      Currently, just over 3000: https://blue.mackuba.eu/directory/pdses https://blue.mackuba.eu/directory/pdses
      - kuschku 4mo ago
        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/ 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://sprk.so/ https://haruhwa.com/ https://haruhwa.com/ (which is an invite-based, snapchat-style ephemeral social network), https://surf.social/ https://surf.social/, https://pckt.blog/ 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.
        ascorbic 4mo ago
        Spark, pckt (and leaflet, tangled) etc aren't using atproto as a compatibility layer: they're fully-fledged apps built on the network.
- cavoirom 4mo ago
  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.
  - palata 4mo ago
    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?
    - cavoirom 4mo ago
      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.
      - ncallaway 4mo ago
        > 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.
deleted 4mo ago
[deleted]
Groxx 4mo ago
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.
- danabramov 4mo ago
  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?
  - Groxx 4mo ago
    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.
    - danabramov 4mo ago
      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.
1dom 4mo ago
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.)
- danabramov 4mo ago
  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.
  - kuschku 4mo ago
    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.
ori_b 4mo ago
"but where are the instances?" is asking "if Bluesky the company disappeared or turned evil, would there be a Bluesky network that kept going?".
matt_kantor 4mo ago
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?
- danabramov 4mo ago
  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.

JasonSage 4mo ago

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.

danabramov 4mo ago
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.
- JasonSage 4mo ago
  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.
- Vinnl 4mo ago
  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.
  - ascorbic 4mo ago
    Currently, just over 3000: https://blue.mackuba.eu/directory/pdses https://blue.mackuba.eu/directory/pdses
    - kuschku 4mo ago
      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/ 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://sprk.so/ https://haruhwa.com/ https://haruhwa.com/ (which is an invite-based, snapchat-style ephemeral social network), https://surf.social/ https://surf.social/, https://pckt.blog/ 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.
      - ascorbic 4mo ago
        Spark, pckt (and leaflet, tangled) etc aren't using atproto as a compatibility layer: they're fully-fledged apps built on the network.
cavoirom 4mo ago
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.
- palata 4mo ago
  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?
  - cavoirom 4mo ago
    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.
    - ncallaway 4mo ago
      > 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.

deleted 4mo ago

[deleted]

Groxx 4mo ago

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.

danabramov 4mo ago
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?
- Groxx 4mo ago
  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.
  - danabramov 4mo ago
    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.

1dom 4mo ago

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

danabramov 4mo ago
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.
- kuschku 4mo ago
  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.

ori_b 4mo ago

"but where are the instances?" is asking "if Bluesky the company disappeared or turned evil, would there be a Bluesky network that kept going?".

matt_kantor 4mo ago

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?

danabramov 4mo ago
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.