Item — HN Reader

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?

4 comments

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

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.

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

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

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?

99.8% on BlueSky PBC. If they turn off federation, it becomes centralised.

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.

A number of PDSes are already defederated from the bluesky relay and even more from the bluesky appview.