Nah it should not. It would hurt decentralization and small instances. We already have a tool for curbing spam, it’s called the Fediseer. You may or may not have heard about it, but most admins have.

Exciting stuff! In particual I really like how neatly organized the project roadmap is, with a quick glance at the project GitHub page I can tell what you guys are working on and how development is proceding.

Also, props for using a widely established language like Java. I know Rust has lots of advantages and is all in all an awesome language, but having to learn a new language just to be able to contribute and submit PRs to your favourite open source project kinda kills the hype (and takes away a bunch of time).

I mainly write JS and not having a backtick on my keyboard annoys the fuck out of me. Other than that the Italian keyboard is alright, never had any other problems with it.

I didn’t, up until yesterday night when you mentioned it. Had a quick Google search and read the wikipedia page, holy fuck there’s some sick people out there. But I still fail to see how defed.xyz could help them doxx or otherwise harass people.

I don’t want to be the author of software used for harassment, obviously, but I don’t think you could use my tool for that, even if you wanted to.

Well of course I can’t guarantee that I would be convinced, even after hearing that but explanation aside

Just because data is publicly scrape-able doesn’t mean it’s acceptable to do so.

Isn’t it? If, an instance admin, has the possibility of hiding some data to the public and refuses to do so, it’s either:

1. Because they are fine with the public accessing it
2. Because they are ignorant and unaware of such a feature, which I honestly don’t think is an acceptable excuse (after all users have entrusted this person with their data, ffs)

At the end of the day what I am doing is nothing more than what any user could do by checking the “Moderated servers” section of the about page of any Mastodon instance.

I’m sorry but I’m really am not seeing the logic behind your point.

I’m sorry could you please elaborate on why the rest of the Fediverse would be enraged, or how this could be used for harassment? I don’t think I follow. I’ll admit, I only interact with the Fediverse through Lemmy so maybe there’s some dynamics of the Masto-sphere I’m not picking up.

My understanding is that Mastodon admins can choose to hide their /domain_blocks endpoint to either outside users or even to all non admins. (source), and as a matter of fact almost a thousand of the 1700 Mastodon instances I’m querying already do so, so really I can only get the federation status of the few hundred that remain.

I think the admins that prefer not to show their defeds, in fear of harassment, are already hiding them, so it should be ok for me to query the remaining ones.

Nice! Glad you were able to find and fix an issue with your instance.

Yeah sure. Assuming you are only targeting Lemmy instances (other softwares make this a bit more complicated), A “can interact” with B if:

• A hasn’t blocked B
• B hasn’t blocked A
• Neither A nor B are on allowlist. If either is on allowlist, it must have explicitly added the other one to its allow list (this is very uncommon, the only big instance using allow lists is hexbear.net)

So, to verify this, you could query the Defed Investigator with the instances you care about, one at a time. Only select the softwares you care about (likely only Lemmy) to make the query faster. Say you wanted to verify the compatibility between lemmy.world and sh.itjust.works (just making an example). Go to https://defed.xyz/check?name=sh.itjust.works&software=lemmy

• ✔ lemmy.world doesn’t appear in the “Instances defederated from sh.itjust.works” (this means .world hasn’t blocked SJW)
• ✔ lemmy.world doesn’t appear in the “Instances defederated by sh.itjust.works” (this means SJW hasn’t blocked .world)
• ✔ lemmy.world doesn’t appear among the “Instances not allowing sh.itjust.works” (this means .world isn’t on allowlist or, if it is, it has explicitly allowed SJW. Again, this is very uncommon)

Also make sure the instance you are looking for isn’t among the “Instances that returned errors”, of course.

Uh interesting. Did you have any fancy custom configuration? Maybe you were blocking all requests to other hosts or something like that? I also have ublock origin and it didn’t give me any troubles.

I have, even Nutomic asked me to, but the thing is I’m a bit of a noob when it comes to Rust. That was my first Rust project ever and the Lemmy backend is big and scary. I would rather gain some proficiency with the language first. Plus, it would likely have to be structured somewhat differently than my implementation if it was integrated into Lemmy proper.

Ah so you were querying programming.dev? In that case I got:
0 defederated from; 3 not allowing; 111 defederated by and 462 federated

Where are you running it from? Because… it works on my device.

Hi. Yeah, both are still active, up and running.

User flairs are currently invisible on my instance because I didn’t get the chance to update my modded UI to the most recent Lemmy version, but the microservice itself is still perfectly operational.

Actually I don’t. After having tested it on the biggest mbin instances, it worked fine on:

• fedia.io
• kbin.run
• kbin.melroy.org
• thebrainbin.org
• rimworld.gallery
• gehirneimer.de
• mbin.0ut0f.space

However I did get the error on:

• kbin.chat
• kbin.life

So whatever it is, it’s not just you. I’m afraid I can’t investigate any further without looking at some instance logs, though.

Not quite, lol.

Some errors will happen, that’s inevitable, CORS is a bitch, but if you are getting that many I’m going to make an educated guess and assume there’s something wrong with either your device or your connection.

There seems to be some problem with your instance’s API. While the federation page works fine, when polling the defederation API at

https://moist.catsweat.com/api/defederated

I am getting the following error:

{
    "type": "https://tools.ietf.org/html/rfc2616#section-10",
    "title": "An error occurred",
    "status": 500,
    "detail": "Internal Server Error"
}

this also gets interpreted as an error by my tool, which is why the green “Instances defederated by …” sections is empty.

Like @iso@lemy.lol said, can’t query from the backend if there is no backend :)

It’s all serverless, so this is as good as it gets.

I’m not too familiar with the drama but any time I visit kbin.social there’s some error or outage going on. Also the documentation is pretty lackluster, developing 3rd party tools for kbin is pretty much impossible.

Mbin looks way more promising, if anything because of the better docs, new features and community-driven direction it’s taking. I hope most kbin users jump ship.

Looks like FediDB is a little drunk lol. Anywaty thanks for the reminder, Blaze. Gonna update mine right now.

I have a bit too much stuff going on in my life right now to focus on changing my Lemmy stack, I’ll have to stick to my current setup for the time being.

But I am very much interested in the package. Gonna leave a star on its repo and hopefully I’ll remember to come back to this once my hands are a bit less full than they are now.

Hey this is pretty cool! I wanted something similar for my instance, with a webhook notifying me of any application request, so I can get a notification and react as soon as possible. Well, I ended up having to implement that from scratch within my @AutoMod@lemmy.basedcount.com bot. A solution like this would probably be WAY more efficient than my current setup (with a client continuously polling for new applications). Good stuff!