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".
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?
> 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".
Great questions! The protocol does have suggested app-agnostic moderation primitives (see https://atproto.com/guides/labels, 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), 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.
> 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.
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).
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.