I thought data caps for home internet were a thing of the past…

For the past 15 years I’ve had a data cap on home internet, but never had a data cap prior to that.

That’s led me to believe the exact opposite of your observation; unlimited data is a thing of the past and data caps are a thing of the present and future.

Here are some basic definitions:

Instance: a Lemmy server with its collection of local users and local communities

Federation: allowing users of one instance the ability to participate and interact with the content and users of another instance

Defederation: “blocking” an entire instance and its users from participating and interacting with the content and users of another instance.

Every instance maintains a publicly visible “instances” list where you can see which instances are allowed/federated (listed as “Linked Instances” and which other instances are disallowed/defederated (listed as “Blocked Instances”. That list is always at the same predictable URL for every instance ( https://[instance]/instances ). For Lemmy.World, that list would be at https://lemmy.world/instances.

Instances operators also have the ability to surgically block specific users or specific communities from other instances. This doesn’t mean they have ‘defederated’, it just means they have blocked a specific use or instance. These are considered moderation activities and show up in an instance’s moderation log (also called the “modlog”). Every instance’s modlog is public and visible at the predictable URL of https://[instance]/modlog. For Lemmy.World, the modlog would be at https://lemmy.world/modlog. The modlog has a “filter by action” dropdown making it easy to find certain types of moderation activities. If you search the modlog for “removing communities” you can see the communities that an instance has removed or blocked.

In the case of the piracy communities, they were removed from Lemmy.world, but federation still exists between Lemmy.world and the other instances where those blocked communities still exist.

You specifically cite the example of piracy going away as a reason for wanting to compare instance’s defederations, but that activity had nothing to do with defederation. Lemmy.world is still federated with the instances that hosted the piracy communities.

Lemmy.world users no longer see it in all/community search results, and if trying to navigate to the Lemmy.world url for the community specifically (like this: https://lemmy.world/c/piracy@lemmy.dbzer0.com ) they just get an error.

So the only way they would discover that communities are blocked is if they absolutely know the community actually exists by visiting the foreign instance.

The only other way I’ve discovered you can see what communities an instance has blocked is by parsing through the public modlog.

dbzer0 is not blocked from lemmy.world - https://lemmy.world/instances.

So while you are technically correct that you can publicly see who is blocking who by looking at their instance list, your answer isn’t relevant to the question of blocked communities where there hasn’t been total instance-blocking.

As far as I can tell, there is no way to see an instance’s blocked communities except by reading/searching their modlog.

They are making an assertion as if it is a statement of fact…and they are, in fact, wrong. That’s ignorant and not helpful for discussion or helpful for understanfing and solving the actual issue. If they had actually asked an innocent question it would be different, but they didn’t. That is why the responses are the way they are.

No, not programmatically. The only way to ‘move’ an instance is for a community of users to create a new community elsewhere and arbitrarily start using it as their preferred community. There is no way to force it and there is no mechanic for moving.

By claiming that the problem isn’t DDOS, you’re just advertising your ignorance. Cloudflair is outstanding for protecting static web content against DDOS, and Lemmy.world is well protected against that. The problem is certain dynamic pages and api calls that can only be rendered from costly realtime dynamic database operations…those are the url that the DDOS attackers are focusing on and those are the kinds of content that cannot be easily protected by cloudflair.

Your premise, though, is still accidently correct. The way to mitigate instances being targeted by DDOS is to spread the user base and community hosting across a vast number of instances so that no one instance is such a rewarding target for DDOS attack.

deleted by creator