Fediverse

Yes, this is still necessary.

It wouldn't make sense to put the onus to block every bad instance onto every single user.

Consider the extreme use case, which is obviously CSAM. I rely on my instance admins to handle that for me. If I had to painstakingly block every instance that has poor moderation (or worse), I'd simply stop using Lemmy. The "all" feed would be utterly unusable.

Also, admins need control over what's in their own database, potentially for legal reasons.

edge lords, tankies, paedophiles, and alt-righters should always be defederated from

Yes. As an admin of an instance who really doesn't want child porn on my server, I'm gonna defederate the shit out of any instance that doesn't take care of such content in a reasonable time. And in my opinion, loli is child porn, so defederating there as well.

Other than that, anything that's illegal in my jurisdiction.

And the last category, spam and bigotry. Basically anything that puts too much work on my plate - if I get dozens of reports a day for users of a single instance (and I agree with the reports), I'll defederate, because no one's paying for my time.

So these are some valid reasons for me to defederate. There are probably more.

Yes.

Instance admins should defederate as often as they feel is necessary, and users should learn to avoid relying on instances that do it too much.

This is the best part about Lemmy: if you disagree with the way an instance is run, you can setup your own and do what you want to do.

Personally I leave it up to people to block instances. The only instances I've had to block are the ones that post illegal content like CSAM.

To combat spam and blatant fuckery, absolutely. Openly hateful places have no business on the general internet.

But anything else is better left to user discretion IMO.

Hey if you're allowed to block instances you want to block, so are instance owners. After all, it's their instance.

Yes, users shouldn't have to jump through a million hoops to get a decent feed.

Instance owners are responsible for the content that is mirrored on their instance through federation, so they definitely should.

Yes. Instance and user defederation are best when used together.

Yes.

What you're describing is basically the way Twitter works, and there's a reason vulnerable folk have migrated away from it in large numbers

Every instance should be able to federate and defederate from any other instance for any, all, or no reason.

The way federation works is that everything is replicated across all federated servers. If an admin team does not want to have to moderate specific kinds of content or users who are deemed detrimental (but not necessarily illegal) they have the ability and right to defederate.

Also, I've blocked servers but it doesn't block users. Defederation does though.

Just give me the tools, as a user, to block instances. Not just the way it is done recently but truly block an instance and all it's posts and users. I want to be able to black hole an entire instance and all things related to it.

The feature only lets you filter posts, not users from that instance.

Other than the obvious criminal instances (CSAM)

I think still yes, when a problem is abundantly clear, but borderline cases can more easily be left to individual preference.

When you block the instance, it's only visible on your client. The fact that they still are federated and content from them is mirrored on your local instance stays unchanged. So they still should defederate with such instances.

@[email protected] yes.

Yes. I think it's especially important for attracting (or perhaps more accurately, maintaining) new users to the fediverse.

It's one of the main differentiators between instances. If you want no filters, you can make your own instance or see if you can find one with a "zero defederation" policy.

E.g. if you don't want to see a bunch of political propaganda or CSAM, and are into programming, programming.dev comes "pre configured" for that. Likewise lemmy.world, blahaj, etc... comes with their own flavour and configuration.