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?
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".
Of course, nothing stops an app from doing moderation differently and not using any of that. This is more for better composability and interoperability.
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?
see 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.
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?
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.
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.