Tags

Moderation Based On Intent

There is a concept in moderation called ‘moderation based on intent’.

A three-strike system or similar might be general policy, but it isn’t always the optimal approach, and sometimes further nuance is necessary.

For example, a newly created account begins to spew bigotry. Should moderators wait for the third occurrence to take action, or should they just be banned immediately? They should be banned immediately, as all parties are aware that there is no intent for positive contribution here, and allowing the disruptive entity to remain causes unnecessary distress to other users.

Offering a path to redemption via a strike system is futile and a waste of resources in such cases. It can also be weaponised and exploited.

Intent can also apply to other situations and be gleaned from context. For example, the term ‘faggot’ could be offensive if used as a slur but benign if used to refer to a bundle of items. The appropriate consequence, if any, is determined by the intent behind the usage of the word.

A ‘based on intent’ clause has been policy for every stable community I’ve moderated, from small groups to large platforms.

In our moderation panel over at Stoat, we have a button to deploy bees.

We don’t want to have to deploy bees, but sometimes that is the only viable option. Releasing bees as a moderation action is always a difficult call to make, but sometimes bees are the only tool for the job.

We have strict policies in place regarding bee usage. As it is, of course, a destructive action, we do also have a confirmation modal to avoid accidental bee deployments.

A word of advice: don’t have a default username system if you’re running an online service which you’ll need to moderate.

Automated accounts will use these default names, which allows them to blend in with genuine users using default names and makes it harder to spot patterns.

Naturally, I generally dislike government censorship. That said, I think Bluesky’s approach to it seems to be relatively decent comparative to other, more mainstream platforms.

Bluesky has a global general moderation system with finer-grained moderation rules based on the law and requests of given jurisdictions. Resisting censorship completely is only going to get the entire platform banned in whatever jurisdiction, which obviously isn’t in Bluesky’s best interests and is arguably worse for the platform overall.

At the very least somebody so inclined can skirt around the country-specific moderation thanks to the openness of the AT Proto. It isn’t a perfect approach, but I think it is generally better than the standard and a reasonable compromise.

Bluesky is decentralised in concept, not in practice. The underlying AT Protocol is pretty open, but it imposes significant technical hurdles for any small player, and – as far as general usage is concerned – Bluesky remains a centralised authority for the wider network.

If you build on the AT Protocol hoping to interface with the wider platform, and Bluesky stops you, you’re more or less dead in the water. Bluesky is the dominant provider and custodian of the network.

They have full control over their moderation policies, feature rollouts, user onboarding, protocol development, etc. As we’ve seen with the introduction of checkmark verification, anyone can technically verify an account, but only Bluesky decides who is trusted, as seen by the majority of people.

I’m not yet saying this is a bad thing, but it is worth considering. Bluesky shouldn’t be lauded as federated, because the authority for the biggest instance (the instance that calls the shots) can very well do what they want. It is federated, but only in the loosest sense.

Bluesky is less federated and more the centre of its own solar system, with the rest of the network rotating around it.