5 ms·

>that also runs the only viable instance? This is a category error. There are no "instances" in atproto. https://overreacted.io/there-are-no-instances-in-atpr

>that also runs the only viable instance? This is a category error. There are no "instances" in atproto. https://overreacted.io/there-are-no-instances-in-atproto/ https://overreacted.io/there-are-no-instances-in-atproto/ It segments the network differently (into "hosting" and "apps"), and on both axes anyone can run their independent app-agnostic hosting, as well as an independent hosting-agnostic app.

account42 3mo ago
This "gotcha" might get cheers from your fellow AT proto fans but only eye rolls from everyone else.
- danabramov 3mo ago
  I don't mean it as a linguistic gotcha ("ha, you said instances! but we call them something else"). I'm saying this is a category error because the network topology is different. This is like saying that web is not free because people aren't running Google-scale indexes in their garages. Tried to clarify this here: https://news.ycombinator.com/item?id=48932956 https://news.ycombinator.com/item?id=48932956
  - demosthanos 3mo ago
    I don't think the Google comparison is doing you any favors in resolving the concern behind the category error, though. What I'm hearing is that AT is like the web if Google had started the web themselves and designed it around their index as the primary means of accessing anything on the web. Sure, they still have Don't Be Evil as their motto at this stage, and in the 90s maybe we would have been naive enough to believe them. But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
    - danabramov 3mo ago
      >designed it around their index as the primary means of accessing anything on the web That doesn't actually translate from the analogy though. You don't use Bluesky to access other apps' data on atproto, you use those apps. You go to https://tangled.org/ https://tangled.org/ for Tangled (atproto github), you go to https://leaflet.pub/ https://leaflet.pub/ for Leaflet (one of atproto blogging platforms), and so on. Bluesky is not a "one stop shop" for all atproto stuff, it's just one of atproto apps, and anyone can make their own app. The apps themselves have to compete on their own merit, completely unrelated to the protocol stuff. The protocol just makes them all interoperable and changes market dynamics (e.g. someone can resurrect a dead app by creating a new projection of existing data). If your criticism is that there aren't many apps on atproto yet — fair, but you can make those! People are making those. This is something you can actively contribute to, there's no permission you need to ask. The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. (Although even that isn't set in stone — see Blacksky who run their own stack for everything, but also show Bluesky posts.) And then, if you make your own app with your own data types, it would not be related to Bluesky in any way. >But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization. Sure, and is your argument that it's better if the web had never happened? Atproto is going to IETF so it will become a "proper" internet standard. The way you shift the balance of power is by building your own stuff on it.
      - demosthanos 3mo ago
        It's great that you can make your own independent apps on atproto, and you're right that I overstated the "anything on the protocol" in the analogy. Analogies are always lossy, but that was worse than necessary. But notice that what you're now arguing is not that Bluesky is equally decentralized to Mastodon as a social network, you are arguing that while Bluesky the app may be in practice highly centralized that doesn't mean other apps can't exist: > The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. It probably is entirely true that different apps can spin up on atproto independently, but that was never the actual point of concern. This, what you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization. Blacksky is an interesting case, and I'm wondering why you didn't roll it out at the beginning and why you still hedge it as "natural" that you'd access the Bluesky app data through Bluesky? I'm actually unfamiliar with the territory here, but coming from my knowledge of the fediverse that seems an odd pairing. If a fully independent implementation exists, why is it natural that you'd use the central one?
  - 1dom 3mo ago
    Dan, you really should refine this line of reasoning a bit as it feels not very nice in some way: it feels like you're picking an unintuitive/uncommon definition for "instance" and then using that to tell everyone they're misunderstanding stuff then they're using different, arguably more widely accepted, definitions. We've had a very similar discussion in response to this same argument recently elsewhere on HN. If you enjoy having this debate, then carry on, but I don't think it endears non ATProto users to the ATProto cause. I think it seems needlessly controversial/pedantic. Sorry for the blunt feedback, it's because I expect better from you:)
    - danabramov 3mo ago
      Let me try to explain my position. The parent post says "the only viable instance" which implicitly packs an assumption of Mastodon-like topology: a single product is expected to be split into many "instances", with some of them being more or less "viable", and that a lack of many "viable" "instances" is perceived as the protocol not being a real thing, or failing to live up to its promise. (How else are you reading "viable instance"?) I believe that if you look at the network topology, this argument becomes much closer to "Google Reader being the only viable instance of Google Reader means RSS is a scam with a single player". Which is an absurd thing to say. That is what I'm trying to show by picking at the word "instance". Do you find my argument flawed, or just the way I present it? How do you prefer I present it alternatively? And how do you read the parent post? My issue isn't with the word, but with the implication in the parent post.
      - 1dom 3mo ago
        I think you're inferring something that people aren't implying, and that inference leads to you eventually discussing how ATProto is better than mastodon. I think this doesn't look great, particularly at a time where there's quite a few posts of about unproductive conflict between open social network contributors. I don't think there's any bad intent or malice on your side: there is value in comparison between AT/AP to help understanding. Your argument that there are no instances in ATProto isn't flawed if you redefine instances as this thing that ATProto doesn't have. But if I run it by the various computer science definitions I can find (e.g. https://en.wikipedia.org/wiki/Instance_(computer_science) https://en.wikipedia.org/wiki/Instance_(computer_science)) then your argument seems like it depends on a niche interpretation. So it can be technically correct, but just irrelevant or inconvenient when used in a comp sci discussion involving the word "instance". But your blog post on the subject is interesting, and informative, and has some great diagrams, and the original parent poster agreed and learned stuff from it. Despite that, I think the implication in the parent post was, IMO, "so the main, largest implementer (instance) of the protocol is also a for-profit which owns the trademarks? I never realised that, I'd assume the protocol was governed and run by a not-for-profit independent governance org, charity or consortium" (like some other open protocols). I think that's a fair and slightly critical implication that has nothing to do with network topology. I completely get how you would want to take issue with that implication alone, because without context like the trademark was acquired with good intent to protect protect openness, and that the Bluesky org is a specific type of for-profit (PBC) that expresses intent to favour public benefit and openness, it makes things sound more sinister than they are. Ultimately, from an openness and independence position, I think it would be better looking from the outside if the ATProto and trademarks were governed and managed by a separate not-for-profit entity that wasn't tied to the biggest instance/implementation of the protocol. I think that was the point being made, and I don't think it's absurd. But I think refuting that argument by focusing on network topology and instance definitions seems like a misunderstanding somewhere.
wwalexander 3mo ago
[flagged]
- danabramov 3mo ago
  I haven't worked at Bluesky for over a year now. I'm genuinely excited about the protocol, and have written a bunch of things about it while I had free time between jobs. (Ironically I had no time to write about it while at Bluesky because I was too busy working around React Native bugs.) >it's impossible to actually participate in Bluesky using an alternative relay I don't know what you mean by this. https://blacksky.community/ https://blacksky.community/ is definitely running their own relay. Here's a community listing of some relays: https://atproto.at/relays https://atproto.at/relays. Here's an example of connecting to one of them: https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.firehose.network https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh.... From an app's perspective, they're completely interchangeable, so as an app developer you can switch to any relay you want, or run your own. Many apps don't even use a relay at all, instead relying on caches like https://constellation.microcosm.blue/ https://constellation.microcosm.blue/.
1shooner 3mo ago
Thanks, this is informative. I had meant 'instance' from more of a general user adoption perspective (i.e. Bluesky app user plus Bluesky PDS tenant), but based on other comments here that may not be too accurate either.

account42 3mo ago

This "gotcha" might get cheers from your fellow AT proto fans but only eye rolls from everyone else.

danabramov 3mo ago
I don't mean it as a linguistic gotcha ("ha, you said instances! but we call them something else"). I'm saying this is a category error because the network topology is different. This is like saying that web is not free because people aren't running Google-scale indexes in their garages. Tried to clarify this here: https://news.ycombinator.com/item?id=48932956 https://news.ycombinator.com/item?id=48932956
- demosthanos 3mo ago
  I don't think the Google comparison is doing you any favors in resolving the concern behind the category error, though. What I'm hearing is that AT is like the web if Google had started the web themselves and designed it around their index as the primary means of accessing anything on the web. Sure, they still have Don't Be Evil as their motto at this stage, and in the 90s maybe we would have been naive enough to believe them. But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
  - danabramov 3mo ago
    >designed it around their index as the primary means of accessing anything on the web That doesn't actually translate from the analogy though. You don't use Bluesky to access other apps' data on atproto, you use those apps. You go to https://tangled.org/ https://tangled.org/ for Tangled (atproto github), you go to https://leaflet.pub/ https://leaflet.pub/ for Leaflet (one of atproto blogging platforms), and so on. Bluesky is not a "one stop shop" for all atproto stuff, it's just one of atproto apps, and anyone can make their own app. The apps themselves have to compete on their own merit, completely unrelated to the protocol stuff. The protocol just makes them all interoperable and changes market dynamics (e.g. someone can resurrect a dead app by creating a new projection of existing data). If your criticism is that there aren't many apps on atproto yet — fair, but you can make those! People are making those. This is something you can actively contribute to, there's no permission you need to ask. The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. (Although even that isn't set in stone — see Blacksky who run their own stack for everything, but also show Bluesky posts.) And then, if you make your own app with your own data types, it would not be related to Bluesky in any way. >But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization. Sure, and is your argument that it's better if the web had never happened? Atproto is going to IETF so it will become a "proper" internet standard. The way you shift the balance of power is by building your own stuff on it.
    - demosthanos 3mo ago
      It's great that you can make your own independent apps on atproto, and you're right that I overstated the "anything on the protocol" in the analogy. Analogies are always lossy, but that was worse than necessary. But notice that what you're now arguing is not that Bluesky is equally decentralized to Mastodon as a social network, you are arguing that while Bluesky the app may be in practice highly centralized that doesn't mean other apps can't exist: > The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. It probably is entirely true that different apps can spin up on atproto independently, but that was never the actual point of concern. This, what you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization. Blacksky is an interesting case, and I'm wondering why you didn't roll it out at the beginning and why you still hedge it as "natural" that you'd access the Bluesky app data through Bluesky? I'm actually unfamiliar with the territory here, but coming from my knowledge of the fediverse that seems an odd pairing. If a fully independent implementation exists, why is it natural that you'd use the central one?
- 1dom 3mo ago
  Dan, you really should refine this line of reasoning a bit as it feels not very nice in some way: it feels like you're picking an unintuitive/uncommon definition for "instance" and then using that to tell everyone they're misunderstanding stuff then they're using different, arguably more widely accepted, definitions. We've had a very similar discussion in response to this same argument recently elsewhere on HN. If you enjoy having this debate, then carry on, but I don't think it endears non ATProto users to the ATProto cause. I think it seems needlessly controversial/pedantic. Sorry for the blunt feedback, it's because I expect better from you:)
  - danabramov 3mo ago
    Let me try to explain my position. The parent post says "the only viable instance" which implicitly packs an assumption of Mastodon-like topology: a single product is expected to be split into many "instances", with some of them being more or less "viable", and that a lack of many "viable" "instances" is perceived as the protocol not being a real thing, or failing to live up to its promise. (How else are you reading "viable instance"?) I believe that if you look at the network topology, this argument becomes much closer to "Google Reader being the only viable instance of Google Reader means RSS is a scam with a single player". Which is an absurd thing to say. That is what I'm trying to show by picking at the word "instance". Do you find my argument flawed, or just the way I present it? How do you prefer I present it alternatively? And how do you read the parent post? My issue isn't with the word, but with the implication in the parent post.
    - 1dom 3mo ago
      I think you're inferring something that people aren't implying, and that inference leads to you eventually discussing how ATProto is better than mastodon. I think this doesn't look great, particularly at a time where there's quite a few posts of about unproductive conflict between open social network contributors. I don't think there's any bad intent or malice on your side: there is value in comparison between AT/AP to help understanding. Your argument that there are no instances in ATProto isn't flawed if you redefine instances as this thing that ATProto doesn't have. But if I run it by the various computer science definitions I can find (e.g. https://en.wikipedia.org/wiki/Instance_(computer_science) https://en.wikipedia.org/wiki/Instance_(computer_science)) then your argument seems like it depends on a niche interpretation. So it can be technically correct, but just irrelevant or inconvenient when used in a comp sci discussion involving the word "instance". But your blog post on the subject is interesting, and informative, and has some great diagrams, and the original parent poster agreed and learned stuff from it. Despite that, I think the implication in the parent post was, IMO, "so the main, largest implementer (instance) of the protocol is also a for-profit which owns the trademarks? I never realised that, I'd assume the protocol was governed and run by a not-for-profit independent governance org, charity or consortium" (like some other open protocols). I think that's a fair and slightly critical implication that has nothing to do with network topology. I completely get how you would want to take issue with that implication alone, because without context like the trademark was acquired with good intent to protect protect openness, and that the Bluesky org is a specific type of for-profit (PBC) that expresses intent to favour public benefit and openness, it makes things sound more sinister than they are. Ultimately, from an openness and independence position, I think it would be better looking from the outside if the ATProto and trademarks were governed and managed by a separate not-for-profit entity that wasn't tied to the biggest instance/implementation of the protocol. I think that was the point being made, and I don't think it's absurd. But I think refuting that argument by focusing on network topology and instance definitions seems like a misunderstanding somewhere.

wwalexander 3mo ago

[flagged]

danabramov 3mo ago
I haven't worked at Bluesky for over a year now. I'm genuinely excited about the protocol, and have written a bunch of things about it while I had free time between jobs. (Ironically I had no time to write about it while at Bluesky because I was too busy working around React Native bugs.) >it's impossible to actually participate in Bluesky using an alternative relay I don't know what you mean by this. https://blacksky.community/ https://blacksky.community/ is definitely running their own relay. Here's a community listing of some relays: https://atproto.at/relays https://atproto.at/relays. Here's an example of connecting to one of them: https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.firehose.network https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh.... From an app's perspective, they're completely interchangeable, so as an app developer you can switch to any relay you want, or run your own. Many apps don't even use a relay at all, instead relying on caches like https://constellation.microcosm.blue/ https://constellation.microcosm.blue/.

1shooner 3mo ago

Thanks, this is informative. I had meant 'instance' from more of a general user adoption perspective (i.e. Bluesky app user plus Bluesky PDS tenant), but based on other comments here that may not be too accurate either.