this post was submitted on 21 Sep 2023
52 points (100.0% liked)

Chat

7499 readers
9 users here now

Relaxed section for discussion and debate that doesn't fit anywhere else. Whether it's advice, how your week is going, a link that's at the back of your mind, or something like that, it can likely go here.

Subcommunities on Beehaw:

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
alyaza@beehaw.org
remington@beehaw.org
52
Instance blocking should replace defederation (lemm.ee)
submitted 1 year ago* (last edited 1 year ago) by HerbalGamer@lemm.ee to c/chat@beehaw.org
63 comments fedilink hide all child comments
 

Think about it; instead of those in charge or the instances deciding who they don't want to be federated with and thus restricting content for the users, it would be better if users were able to block entire instances instead.

We'd be able to curate our own browsing experience so much better without admin/mod drama influencing the rest of us.

Edit: Alright so maybe not exactly replace defederation, but it should still be an option available to us, and in general should become the default action before defederation IMHO.

you are viewing a single comment's thread
view the rest of the comments
[–] BarryZuckerkorn@beehaw.org 4 points 1 year ago

I'm sympathetic to the idea that an individual user should be able to override their instance admins' preferences on access for content-related reasons, but I don't think it would be workable from an administrative viewpoint to allow users to allowlist instances that were blocklisted for administrative reasons.

Lemmy.world dealt with (and is probably still dealing with) a series of malicious actions designed to actually bring down the service or otherwise tie up its resources (including moderator/admin attention and effort, and exposure to literal criminal charges), using maliciously crafted requests to bring down servers, literally illegal content posted to their servers, etc. Defederation in response to these types of attacks would be defeated if a user could let the content come through anyway.

I imagine most instances are dealing with similar issues.

So ideally we'd need to be able to create 4 categories of relationships with other instances:

  1. Blocked no matter what
  2. Blocked by default for users, can be user overridden
  3. Allowed by default for users, can be user overridden
  4. Allowed no matter what (not sure what the use case for this status would be, but seems to be trivial to implement since it already exists as default).

But I think you'd find that the typical scenario that justifies blocking would actually put the typical block into category 1, not category 2.