39 ms·

I appreciate how this explains the difference between the two. But I also found it a little frustrating, because it answered one part of the question but faile

I appreciate how this explains the difference between the two. But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve? For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto solve the problems that defederation solves?". Because the default reasonable answer to assume, given this framing, is "it doesn't".

danabramov 4mo ago
If you’re asking about moderation, it works similarly as you’d expect it to work in a everything-RSS world. At the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things. At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content. There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices. Does this help clarify it?
- JoshTriplett 4mo ago
  > Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). This is the part I would be looking for, in an article talking about "there are no instances". Is there a standard protocol for this, so that anyone can spin up a shared moderation service that people can subscribe to if they're aligned with it, and be able to plug that into any standard app built on the protocol (not just Bluesky-the-company's app)? Or is this something specific to Bluesky-the-company? If this is a standardized part of the protocol, then that answers the question of "how does ATProto solve the same problems defederation solves". There are several other things I can think of in the category of "how do you solve the problems that ActivityPub uses instances to solve", but they're things I've already asked in other parts of this thread, namely "how do you make the parts of the system not shown in the tidy hosts->apps M:N graph decentralized, too".
  - danabramov 4mo ago
    Great questions! The protocol does have suggested app-agnostic moderation primitives (see https://atproto.com/guides/labels https://atproto.com/guides/labels, https://atproto.com/guides/creating-a-labeler https://atproto.com/guides/creating-a-labeler). That's the basis of how Bluesky's own moderation works under the hood. There's also Bluesky-specific tools and APIs like Ozone (https://atproto.com/guides/using-ozone https://atproto.com/guides/using-ozone), but they build on top of those primitives. Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
    - JoshTriplett 4mo ago
      I had seen the mentions of labelers, though it hadn't been clear that that was something general beyond Bluesky-the-app, thank you. This would have been helpful to have in the article, alongside the mentions of defederation. When people are asking about instances, sometimes what they want to know is how you solve the same set of problems they care about, so here are the solutions to those problems, etc.
- allwashedup 4mo ago
  How is it any different than a centralized social media service then? Merely the fact that you can get a firehose from the website in a standard format? This was already the case with HTTP. The problem is that websites can leverage their power to make a locked-in ecosystem. see https://www.youtube.com/watch?v=BxV14h0kFs0 https://www.youtube.com/watch?v=BxV14h0kFs0 twitter, etc once had a much more open API. so did reddit. This was just the first stage of their penetration strategy. The decentralization is totally irrelevant due to the way it's implemented. The problem is that Apps are sticky, so app developers have undue power to control their users. The "content hosts" "moderators" etc need to be completely cut out of the picture to be at the same level of censorship resistance as an RSS-shared blog. I can host a blog on my own computer, and you can subscribe to it without that many intermediaries.
  - danabramov 4mo ago
    Sure, you could say it’s a set of conventions on top of what you’re describing — that imo is sufficient to shift the incentive picture. It’s a firehose of typed JSON that’s canonically stored at URLs that survive hosting changes and can link to other JSON. It’s signed and verifiable and links to other JSON. So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch. I think that makes a big difference. Don’t you think?
    - allwashedup 4mo ago
      [dead]
    - inigyou 4mo ago
      99.8% on BlueSky PBC. If they turn off federation, it becomes centralised.
    - zoul 4mo ago
      New services don’t start with the same userbase because users don’t use protocols, they use apps. And for Bluesky that’s predominantly a single centralized app. If that demotes content from the “competitors” or even switches the protocol completely, you are stuffed. The apps are very much not equal.
- rtpg 4mo ago
  > There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. If Bluesky specifically wanted to just not have its user interact with some other entity in ATProto-land would they be able to? My impression is that the answer to this is "yes", because people are signing up to Bluesky and relying on Bluesky to hold on to their posts etc. Similar to how Email is all federated but in practice a bunch of people use email from one of a handful of large service providers who (in practice, not necessarily for nefarious reasons) do end up blacklisting certain email senders. The RSS-reader example feels a bit different on the ground because for a given user, "store a list of websites you care about" is not a complicated endeavor. For the "short-form social media with algorithmic timeline" usecase (which isn't all atproto is about, granted!) "users self-host a thing to scoop up enough of the world's posts to then make a local algorithmic timeline" doesn't... doesn't feel very feasible, right? I guess the blogspot comparison is apt... but if "full" self-hosting requires a relay with quite some juice ($30 is "cheap" but... compared to a pile of files to host your own blog...), then in practice we're going to see a heavy amount of centralization anyways right?
- inigyou 4mo ago
  A number of PDSes are already defederated from the bluesky relay and even more from the bluesky appview.
NoGravitas 4mo ago
It doesn't solve those problems, except in an alternative universe where there are a very large number of appviews capable of consuming the entire firehose and you can freely choose between them and cheaply run your own. ATProto is like RSS in a universe where you can only read RSS through Google Reader (or a clone of Google Reader running on the same scale).
- danabramov 4mo ago
  I don’t know what you’re saying. I’m running an atproto app and it’s perfectly capable of ingesting the entire firehouse as it comes in. It costs me maybe $10/mo and mostly because I haven’t fixed some memory leaks. Of course, few of records that come through are relevant to my app so I don’t store them. If I wanted to store gigabytes of records (like Bluesky) for millions of users forever then yes it would be more expensive. Which would be the case with any tech! What are you comparing it to? How is this a downside of atproto? Mastodon instances aren’t a valid comparison point because by definition they’re small-world. They don’t serve millions of users. If your point is that you want small-world atproto, that’s absolutely possible. Take the Bluesky server codebase and make it so that it ignores incoming content beyond some criteria (like “follows of server member list”). You can recreate Mastodon experience on atproto, it just hasn’t been very interesting to anyone so far AFAIK.
  - zoul 4mo ago
    I think we are all saying that Mastodon is meaningfully decentralized and there is no single party that could pull the rug from beneath the whole network. This is what instances bring to the table. Bluesky may be architecturally beautiful, but it’s not decentralized in practice. (See https://arewedecentralizedyet.online https://arewedecentralizedyet.online for example.) And we know what tends to happen to important centralized services.
AnthonyMouse 4mo ago
> it fails to answer "so how does atproto solve the problems that defederation solves?". The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances. It's an architectural choice that has the long-term effect of cementing an oligopoly. Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default. Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.

danabramov 4mo ago

If you’re asking about moderation, it works similarly as you’d expect it to work in a everything-RSS world. At the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things. At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content. There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices. Does this help clarify it?

JoshTriplett 4mo ago
> Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). This is the part I would be looking for, in an article talking about "there are no instances". Is there a standard protocol for this, so that anyone can spin up a shared moderation service that people can subscribe to if they're aligned with it, and be able to plug that into any standard app built on the protocol (not just Bluesky-the-company's app)? Or is this something specific to Bluesky-the-company? If this is a standardized part of the protocol, then that answers the question of "how does ATProto solve the same problems defederation solves". There are several other things I can think of in the category of "how do you solve the problems that ActivityPub uses instances to solve", but they're things I've already asked in other parts of this thread, namely "how do you make the parts of the system not shown in the tidy hosts->apps M:N graph decentralized, too".
- danabramov 4mo ago
  Great questions! The protocol does have suggested app-agnostic moderation primitives (see https://atproto.com/guides/labels https://atproto.com/guides/labels, https://atproto.com/guides/creating-a-labeler https://atproto.com/guides/creating-a-labeler). That's the basis of how Bluesky's own moderation works under the hood. There's also Bluesky-specific tools and APIs like Ozone (https://atproto.com/guides/using-ozone https://atproto.com/guides/using-ozone), but they build on top of those primitives. Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
  - JoshTriplett 4mo ago
    I had seen the mentions of labelers, though it hadn't been clear that that was something general beyond Bluesky-the-app, thank you. This would have been helpful to have in the article, alongside the mentions of defederation. When people are asking about instances, sometimes what they want to know is how you solve the same set of problems they care about, so here are the solutions to those problems, etc.
allwashedup 4mo ago
How is it any different than a centralized social media service then? Merely the fact that you can get a firehose from the website in a standard format? This was already the case with HTTP. The problem is that websites can leverage their power to make a locked-in ecosystem. see https://www.youtube.com/watch?v=BxV14h0kFs0 https://www.youtube.com/watch?v=BxV14h0kFs0 twitter, etc once had a much more open API. so did reddit. This was just the first stage of their penetration strategy. The decentralization is totally irrelevant due to the way it's implemented. The problem is that Apps are sticky, so app developers have undue power to control their users. The "content hosts" "moderators" etc need to be completely cut out of the picture to be at the same level of censorship resistance as an RSS-shared blog. I can host a blog on my own computer, and you can subscribe to it without that many intermediaries.
- danabramov 4mo ago
  Sure, you could say it’s a set of conventions on top of what you’re describing — that imo is sufficient to shift the incentive picture. It’s a firehose of typed JSON that’s canonically stored at URLs that survive hosting changes and can link to other JSON. It’s signed and verifiable and links to other JSON. So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch. I think that makes a big difference. Don’t you think?
  - allwashedup 4mo ago
    [dead]
  - inigyou 4mo ago
    99.8% on BlueSky PBC. If they turn off federation, it becomes centralised.
  - zoul 4mo ago
    New services don’t start with the same userbase because users don’t use protocols, they use apps. And for Bluesky that’s predominantly a single centralized app. If that demotes content from the “competitors” or even switches the protocol completely, you are stuffed. The apps are very much not equal.
rtpg 4mo ago
> There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. If Bluesky specifically wanted to just not have its user interact with some other entity in ATProto-land would they be able to? My impression is that the answer to this is "yes", because people are signing up to Bluesky and relying on Bluesky to hold on to their posts etc. Similar to how Email is all federated but in practice a bunch of people use email from one of a handful of large service providers who (in practice, not necessarily for nefarious reasons) do end up blacklisting certain email senders. The RSS-reader example feels a bit different on the ground because for a given user, "store a list of websites you care about" is not a complicated endeavor. For the "short-form social media with algorithmic timeline" usecase (which isn't all atproto is about, granted!) "users self-host a thing to scoop up enough of the world's posts to then make a local algorithmic timeline" doesn't... doesn't feel very feasible, right? I guess the blogspot comparison is apt... but if "full" self-hosting requires a relay with quite some juice ($30 is "cheap" but... compared to a pile of files to host your own blog...), then in practice we're going to see a heavy amount of centralization anyways right?
inigyou 4mo ago
A number of PDSes are already defederated from the bluesky relay and even more from the bluesky appview.

NoGravitas 4mo ago

It doesn't solve those problems, except in an alternative universe where there are a very large number of appviews capable of consuming the entire firehose and you can freely choose between them and cheaply run your own. ATProto is like RSS in a universe where you can only read RSS through Google Reader (or a clone of Google Reader running on the same scale).

danabramov 4mo ago
I don’t know what you’re saying. I’m running an atproto app and it’s perfectly capable of ingesting the entire firehouse as it comes in. It costs me maybe $10/mo and mostly because I haven’t fixed some memory leaks. Of course, few of records that come through are relevant to my app so I don’t store them. If I wanted to store gigabytes of records (like Bluesky) for millions of users forever then yes it would be more expensive. Which would be the case with any tech! What are you comparing it to? How is this a downside of atproto? Mastodon instances aren’t a valid comparison point because by definition they’re small-world. They don’t serve millions of users. If your point is that you want small-world atproto, that’s absolutely possible. Take the Bluesky server codebase and make it so that it ignores incoming content beyond some criteria (like “follows of server member list”). You can recreate Mastodon experience on atproto, it just hasn’t been very interesting to anyone so far AFAIK.
- zoul 4mo ago
  I think we are all saying that Mastodon is meaningfully decentralized and there is no single party that could pull the rug from beneath the whole network. This is what instances bring to the table. Bluesky may be architecturally beautiful, but it’s not decentralized in practice. (See https://arewedecentralizedyet.online https://arewedecentralizedyet.online for example.) And we know what tends to happen to important centralized services.

AnthonyMouse 4mo ago

> it fails to answer "so how does atproto solve the problems that defederation solves?". The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances. It's an architectural choice that has the long-term effect of cementing an oligopoly. Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default. Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.