Discussion
Loading...

Post

  • About
  • Code of conduct
  • Privacy
  • About Bonfire
Hazelnoot
@hazelnoot@enby.life  ·  activity timestamp 6 days ago

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

  • Copy link
  • Flag this post
  • Block
The Nexus of Privacy
@thenexusofprivacy@infosec.exchange replied  ·  activity timestamp 5 days ago

Agreed. This is also one of the recommendations in Erika Melder et. al.'s excellent "A Blocklist is a Boundary” (in section 5.1.1):

A simple technical change that Fediverse platforms may consider to help alleviate conflict is more refined tiers of blocking. Currently, the only tiers of blocking another instance are limiting, which removes the instance’s content from the public feed, or defederating, which cuts off that instance entirely. More granular options would allow instances to continue to federate with other instances under certain restrictions, which would help resolve certain issues over differing norms without resorting to defederation. For example, the ability to hide all profile pictures from a given instance would prevent instances that ban explicit content in profile pictures from having to defederate instances that allow it. With more flexibility in moderation tools, instances could also then implement tiered sanctions, as recommended by Kiesler et al. [50], to mitigate some of the confrontational effects of community boundary blocklists and operate with the “lighter touch” that many participants wished to see.

@hazelnoot

  • Copy link
  • Flag this comment
  • Block
julian
@julian@activitypub.space replied  ·  activity timestamp 6 days ago

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

@hazelnoot@enby.life I think you hit the nail on the head. A lot of the existing moderation controls are heavy-handed because there hasn't been enough work done to improve the options.

I think perhaps this could be something addressable via policy via the SWICG Trust & Safety Task Force ( @thisismissem@hachyderm.io)... an information FEP that lays out the a recommended baseline of moderation actions in order to better support volunteer moderators.

  • Copy link
  • Flag this comment
  • Block
Log in

Bonfire Dinteg Labs

This is a bonfire demo instance for testing purposes. This is not a production site. There are no backups for now. Data, including profiles may be wiped without notice. No service or other guarantees expressed or implied.

Bonfire Dinteg Labs: About · Code of conduct · Privacy ·
Bonfire social · 1.0.0-rc.3.15 no JS en
Automatic federation enabled
  • Explore
  • About
  • Code of Conduct
Home
Login