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.
That’s odd. My instance shows up as blocked by several other instances. Yet when I check those instances, they show my instance as one of the linked instances.
I’ve been using https://fba.ryona.agency which does the same.
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.
Please don’t feed them data about fediverse instances by querying new domain names.
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.
what is exactly the purpose of knowing who is blocked by whom?
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.
Knowing who blocks that instance at most gives you a hint if an instance is generally considered a bad actor.
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 are 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.
Further more: what is exactly the purpose of knowing who is blocked by whom?
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.
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 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.
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.
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.
Idk what’s hard about it.
SJW is blocked by Beehaw, I wanna see beehaw and SJW, I check the tool, I input lemm.ee, I see lemm.ee has both SJW and Beehaw and is not banned by anyone big, I join lemm.ee
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.
