How to use:
The url must be the hostname only, NO SLASHES, like this: lemmy.dbzer0.com
, don’t use https://, don’t append a slash afterwards (lemmy.dbzer0.com/
), only the hostname including the subdomain if it has it (in this case, lemmy
).
If the instance has blocked the IP address from the server, or it is stuck and its API is not working correctly, it returns “Not a Lemmy instance” (I am too busy to fix this right now).
If the url is not formatted in a way it can process it, it will say Invalid URL. Better processing can come in the future. I won’t be updating it now.
- URL: https://federation-checker.vercel.app/
- Source code: https://github.com/lemmygod/federation-checker
In the backend, it just scrapes https://fba.ryona.agency/?domain={url}
and uses the api https://{instance}/api/v3/federated_instances
PRs welcome.
Honestly it works better when deployed locally in a development environment. I think Vercel’s IP address is just blocked by cloudflare and other blacklists that stop automated stuff? Idk. Can check back in a few days.
This tool is primarily used for ban evasion and harassment and is run by people from kiwifarms (a known bad actor on the fediverse).
Please don’t feed them data about fediverse instances by querying new domain names.
Further more: what is exactly the purpose of knowing who is blocked by whom? All it does is stirr drama and it will be used for harassment.
I don’t believe searching for domains will feed them data as such. You can crawl the lemmyverse starting from a few known servers. It’s how awesome-lemmy-instances works.
Before joining an instance it seemed useful to get an idea of their moderation policy. It just gives transparency as to that instance’s policies, as well insight into how the rest of the fediverse views that instance.
I wasn’t aware it was created by known bad actors and it wasn’t my intention to promote them. It was just a useful tool.
Yes querying for new instances in that tool will make it aware of them and from then on it will start tracking these instances block list.
And I don’t see how this helps at all. You can figure out the moderation policy by looking at the block list of the instance. Knowing who blocks that instance at most gives you a hint if an instance is generally considered a bad actor, but that is usually immediately visible by looking at their local feed.
Nope. It only tells you who dislikes it for any reason. Is sh.itjust.works a bad actor? Is lemmy.world a bad actor? If not, then why did Beehaw.org block them? According to them it was because they were open registration. Misunderstandings like these are common.
If, because I follow your advice, I join sh.itjust.works and I don’t have Beehaw content available because I am blocked, is it because I’m a bad actor? Nope, I just picked the wrong instance. Nothing wrong in looking through the list to see who isn’t blocking what you want to see and joining that.
Both these instances where temporarily blocked by beehaw as they couldn’t get trolls originating from these two instances under control otherwise.
The lack of registration screening on a federated network is at best a sign of severe mis-management and you really should not join such instances as long as this situation remains as it is.
Yup. And if I wanna interact with Beehaw, I need to do it from elsewhere. In my case, I use Lemm.ee because it has both SJW and Beehaw.
I joined right after SJW was created. I had no idea there would be problems with management. Many people don’t even know about this. And how could they, if they don’t check the list of instances that are blocked or asked why such and such are blocked?
Still, that doesn’t mean that there aren’t valuable communities in SJW. If I wanna interact with them, I need to know from where I can do that, and from where I can’t. From Beehaw, for example, I can’t. So after checking the little tool I’d know that Beehaw is not the right community to join because it sucks cuz it has too much banned stuff that I wanna see.
There’s good reason as a regular Lemmy user. To properly interact with a remote community you need the instance of the community linked on your sign-in instance and you need your sign-in instance linked on the remote instance.
For example if I sign in on lemmy.ml and I want to interact with a community local to beehaw.org, I have to go to beehaw.org/instances and check lemmy.ml is linked. Then I have to go to lemmy.ml/instances and check beehaw.org is linked. It’s kind of an unruly task with the /instances lists as large as they are so a tool to check that for you is very useful.
No you don’t. Unless an instance is explicitly blocked, linking is automatic and happens as soon as you start interacting with another instance.
The purpose is not to link, but to know whether it’s linked. Sometimes you wanna know if your recipient is gonna be getting your messages before you send them. Sometimes you wanna know if the email provider you’re signing up to can even get emails from Gmail before singing up to it.
As I said, linking is automatic. You don’t need to know if something is linked as it is automatically linked as soon as you want.
And gmail is an exceptionally bad example as they spamblock just about anyone other that a few others that are too big to block. And they do so for pure business reasons as they want you to switch to gmail.
And I said, the purpose is not to link. Linking is not the purpose. It has nothing to do with the purpose.
The purpose is to interact. This tool checks if you can interact. Sometimes you can, sometimes you can’t, simple as that. If you want to interact but the instance you’re considering can’t, then you put it in your back pocket and keep looking.
Yeah bad example. It’s more like you have a sniper’s rifle and you wanna see if you can pop a head or whether that head is vaccinated against the exact brand of bullet that you’re carrying. Except instead of bullet it’s a comment, and instead of head it’s a post that you wanna comment on.
Okay, let me say not blocked. Yes linking is automatic, but if an instance appears in the linked column, it can’t appear in the blocked column. You want to check that neither instance is blocked, which is the same as saying both instances are linked.
POV: you’re joining an instance. You check the tool. The instance is blocked by instances that have communities you like. You decide not to join that instance, and instead check the tool to find a place that 1. Doesn’t block what you like and 2. Is not blocked by what you like. Seems easy enough to understand to me, especially since sh.itjust.works got defederated by beehaw.org and everyone is talking about defederating this and that over some reason or another.
Why would you not directly join an instance that has the communities you like?
Even playing devils advocate here I can at best see it as a tool to figure out which instances to avoid completely, but you can get about the same information by looking at the block-list of any instance that you like.
Not OP, but my communities are homed on a number of different instances. At minimum, I need to be able to interact with them, both reading and widely distributing my posts/comments. Preferably all on the same account, but that’s gotten more difficult lately.
For any communities I may create, I generally want to ensure that they can be accessed widely, by most users in the fediverse.
All of this preferably without having to deal with tankies, Nazis, etc.
Idk what’s hard about it.
It’s a pretty simple thought process.
Another level of complexity is, for example, knowing that lemm.ee bans nsfw content and you can’t post it. What if you want nsfw? You check the tool again, find lemmy.zip which doesn’t have nsfw blocked and has not blocked or been blocked by SJW and Beehaw and many others, you sign up, and you have all you want. What’s so hard or bad about that?
This kind of “what’s best for me alone in the short term” thinking is absolutely destructive to a federated network and is really only a small notch above intentional ban evasion.
I feel that you’re somehow missing the entire point. I’m not looking to evade any bans. If I wanna read news from beehaw.org and sh.itjust.works on the same Subscribed feed, and potentially interact with the comments, I cannot do that from either sh.itjust.works or beehaw.org, but I need to go to a third instance that has both available. Am “I” as an individual banned? No. Am I part of the target group banned? No. I am simply caught in the crossfire. To pretend like, by doing this, I am somehow harming federation, is not realistic for me.
You have to think about this a bit broader. You are one of many actors in a federated network that together help shape the network.
Let’s say Facebook opens a fediverse instance (which they will soon do) and most of the well managed instances imediatly block them since they are a known bad actor and actively harmful to the ecosystem.
If you now intentionally look for a instance that federates both with these instances and the one run by Facebook, that is a form of ban evasion that is indirectly detrimental to the health of the Fediverse.
No it isn’t. Let’s say I join “littlehorseylemmy.org” which has, say, 30 people, and I just wanna see what the facebookers are doing and what the regular lemmings are doing, as long as I am not sharing content between sides, I am not even affecting any of both sides.
This is short term thinking.
Instances block other bad actor instances to either get them to stop being bad actors or to isolate them from the network. Its a kind of built in immune system so to say.
By intentionally choosing to not participate in this collective effort you are at best a fool directly helping Facebook to get a foothold in the Fediverse.