"i'm not going to go so far as to say 'centralization is good', but in a centralized system, a personality clash between a couple internet janitors might lead to a new subforum being made that a few users might choose to go to. in a decentralized system, a personality clash between internet janitors leads to platform-wide technological incompatibilities for thousands of users who have nothing to do with it."

news.ycombinator.com/item?id=3

This is fair comment in some ways. But ...

(1/?)

Service-level moderation cuts both ways.

It enables all posts sent by a spam server to be refused by an admin, for everyone on their service. Instead of everyone having to individually identify the spam pattern, and Mute/Block the server for their account.

But that same tooling also enables an admin to censor a service that gives a platform to indigenous peoples, or gender nonconforming folk. Getting rid of this risk of censorship also stops admins from stopping spammers at the gate.

(2/?)

Nostr and BlueSky's ATProto try to solve the problem by separating hosting from moderation. They're often described by Mastodon stans as devolving all moderation responsibility to the account level. But that's not really accurate, in either network.

In Nostr, relay operators can make mod decisions about what they will and won't relay. But since you can use multiple relays at once, no one relay operator can have final say over what you get to see;

idiomdrottning.org/nostr-moder

(3/?)

Similarly in the ATmosphere, BlueSky can moderate what's visible in the AppView and Relay they operate, and probably what can be stored in a PDS hosted by them. But if you host your PDS somewhere else, and use an AppView/ Relay hosted by BlackSky, or Free Our Feeds, or anyone else, then BlueSky has no say whatsoever in what you do and don't see.

ATProto has a labelling system that allows people to opt-in to moderation-as-a-service. AFAIK Nostr has tools that make this possible there too.

(4/?)

There's been a lot of discussion over the last year or 2 about what the ActivityPub-based fediverse can learn from these newer networks. I think separating moderation from hosting is definitely one of them.

People who are good at hosting servers are not always good at moderation, or recruiting and overseeing an effective mod team. People who are good at Trust & Safety don't necessarily know how to run servers sustainably. Making people do both, to do either, is setting them up to fail.

(5/?)

There's something to be said for taking a totally different approach to onboarding. Where we help the fediverse grow organically, by inviting people we know to join services we run, or run by people we know and trust.

Arguably signing up for random online services run by total strangers is an artifact of the puberty of the net. Another self-compromising net habit we need to move on from, as we leave the era of profit-obsessed DataFarming platforms.

(7/?)

~4 more replies (not shown)

But regardless, it's worth considering how moderation might look if we applied the same informed consent principle we talk about in regard to search, bridging, and other aspects of the fediverse. In that scenario, the moderation run by the people hosting the service would have to be optional, not compulsory. Not only that, it would have to be opt-in.

(8/?)

At minimum devs need to make moderation opt-out in their fediverse software. But admins still need to be free to choose not to host certain kinds of posts in their database. How do we do both?

The answer is that if Alice chooses to turn off moderation for her account, posts from accounts or service excluded from the service she's using are loaded like websites, from the service where they were posted.

(9/?)

#FediverseIdeas

The beauty of opt-out moderation is that admins can't be forced to host posts they strongly object to. But they have no power of censorship over what people using their service can see.

Also, members can audit their mods at any time, individually or as a group. Simply by turning off moderation for a while.

But widely blocked services will end up dealing with much heavier web traffic than those that aren't. Creating an incentive for service operators to play nicely with others.

(10/?)

Before someone says that I'm basically describing Nostr, I'm aware of the parallels. But what I'm talking about is a bit different again. Because it retains the concept of a service; storage, distribution, browsing and moderation, all in one convenient, easy-to-understand package.

It just makes the moderation part less useful as a tool for power-tripping and empire building, and makes mod services more accountable to the people using them.

(11/11)