I think defederation (fediblocks) would be way less harmful to users if the main backend software (Mastodon, xOma, xKey, and G2S) offered more fine-grained federation controls.

Currently, Mastodon has the most limited options - those being the traditional suspend/silence along with a few feature-specific toggles and bare-bones filter support. Pleroma and Akkoma offer very powerful filters, but they can be tricky for an average mod to use. Plus they're largely focused on filtering individual AP objects in a pipeline which limits their usefulness somewhat. Misskey-based software varies a lot, but generally has powerful role and regex-based filtering that's hamstring by broken implementations of user-level controls like blocks and mutes. I'm less familiar with GoToSocial, but they seem to have plans for fine-grained moderation that hasn't quite materialized because the software is relatively new.

All that inconsistency leads people to rely on the common denominator of features: silence and suspend. These are both fairly "heavy" actions - the former is an instance-wide shadowban, and the later extends that into a full ban. These two features comprise the "fediblock" behaviors that often frustrate new users.

From the perspective of an average user, instances are a rather vague concept and it may not be apparent how they fit within "the network". If you want to follow your friend (who you know is a good person), but find that they're blocked, an answer of "it's because they're on whatever.instance" doesn't make any sense. And why would it, really? It's weird for someone who has never broken any rules to be banned by your moderators.

So as a moderator, you have a few choices. You can try to explain the whole concept of federation and blocks, with the risk that your user gets confused and just leaves instead. You could also lower the suspension to a silence, but what if the block was in place for good reason? You'd put the rest of your users in danger. And finally, you do have the choice of just putting your foot down and drawing a hard line - complete with the knowledge that your users will see you no differently than any corporate platform mod.

None of those are good choices. Actually, I'd go further and say they all suck absolute ass. But there is an option that cleanly resolves the issue with no downsides: a fine-grained override to allow that exact user to federate. The risk is minimal because you have a local user to vouch for the remote one, and the relaxed federation doesn't extend to anyone else. If necessary, you can make it even more narrow by allowing federation between those two users only. Then your user can talk to their friend, and no one else is exposed to the friend or their instance. Safety is maintained, and the "network" is intact from the user's point of view. It's a win-win.

Except, of course, that nothing actually supports that. So even though a perfect solution exists and would require no protocol changes, we can't use it because none of the software offers precise-enough controls. The answer exists, it just hasn't been implemented yet.

#Fedi #FediDev #Moderation #Federation

I think defederation (fediblocks) would be way less harmful to users if the main backend software (Mastodon, xOma, xKey, and G2S) offered more fine-grained federation controls.

Currently, Mastodon has the most limited options - those being the traditional suspend/silence along with a few feature-specific toggles and bare-bones filter support. Pleroma and Akkoma offer very powerful filters, but they can be tricky for an average mod to use. Plus they're largely focused on filtering individual AP objects in a pipeline which limits their usefulness somewhat. Misskey-based software varies a lot, but generally has powerful role and regex-based filtering that's hamstring by broken implementations of user-level controls like blocks and mutes. I'm less familiar with GoToSocial, but they seem to have plans for fine-grained moderation that hasn't quite materialized because the software is relatively new.

All that inconsistency leads people to rely on the common denominator of features: silence and suspend. These are both fairly "heavy" actions - the former is an instance-wide shadowban, and the later extends that into a full ban. These two features comprise the "fediblock" behaviors that often frustrate new users.

From the perspective of an average user, instances are a rather vague concept and it may not be apparent how they fit within "the network". If you want to follow your friend (who you know is a good person), but find that they're blocked, an answer of "it's because they're on whatever.instance" doesn't make any sense. And why would it, really? It's weird for someone who has never broken any rules to be banned by your moderators.

So as a moderator, you have a few choices. You can try to explain the whole concept of federation and blocks, with the risk that your user gets confused and just leaves instead. You could also lower the suspension to a silence, but what if the block was in place for good reason? You'd put the rest of your users in danger. And finally, you do have the choice of just putting your foot down and drawing a hard line - complete with the knowledge that your users will see you no differently than any corporate platform mod.

None of those are good choices. Actually, I'd go further and say they all suck absolute ass. But there is an option that cleanly resolves the issue with no downsides: a fine-grained override to allow that exact user to federate. The risk is minimal because you have a local user to vouch for the remote one, and the relaxed federation doesn't extend to anyone else. If necessary, you can make it even more narrow by allowing federation between those two users only. Then your user can talk to their friend, and no one else is exposed to the friend or their instance. Safety is maintained, and the "network" is intact from the user's point of view. It's a win-win.

Except, of course, that nothing actually supports that. So even though a perfect solution exists and would require no protocol changes, we can't use it because none of the software offers precise-enough controls. The answer exists, it just hasn't been implemented yet.

#Fedi #FediDev #Moderation #Federation