this post was submitted on 27 Jun 2023

303 points (100.0% liked)

/kbin meta

2 readers

1 users here now

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

founded 2 years ago

303

Lemmy.ml is blocking all requests from /kbin Instances (kbin.social)

submitted 2 years ago* (last edited 2 years ago) by barista@kbin.social to c/kbinMeta@kbin.social

125 comments fedilink hide all child comments

I discovered yesterday evening that Lemmy.ml is blocking all inbound ActivityPub requests from /kbin instances. Specifically, a 403 'access denied' is returned when the user agent contains "kbinBot" anywhere in the string. This has been causing a cascade of failures with federation for many server owners, flooding the message queue with transport errors.

This doesn't appear to be a mistake; it has been done very deliberately, only on Lemmy.ml. Lemmy.world and other large instances do not exhibit the same behavior. It also isn't a side effect of the bug introduced in Lemmy 0.18. You can observe by sending the following in a terminal

> curl -I --user-agent "kbinBot v0.1" https://lemmy.world/u/test
HTTP/2 200
[...]

> curl -I --user-agent "kbinBot v0.1" https://lemmy.ml/u/test                                
HTTP/2 403
[...]

> curl -I --user-agent "notKbinBot v0.1" https://lemmy.ml/u/test
HTTP/2 403
[...]

> curl -I --user-agent "placeholder-user-agent" https://lemmy.ml/u/test
HTTP/2 200
[...]

Additional evidence of this not being a Lemmy 0.18 bug:

This occurs when making web requests to any location on the Lemmy.ml webserver, not just ActivityPub endpoints.
Go to https://fedidb.org/software/lemmy and pick an instance running 0.18.0. Perform the above commands, replacing the URL for Lemmy.ml with that particular instance's address.

If this continues, my instance may need to defederate from Lemmy.ml. This is especially problematic because Lemmy.ml continues to federate information outbound to other kbin instances while refusing to allow inbound communication from them.

Spoofing the user agent is less than ideal, and doesn't respect Lemmy.ml's potential wish to not be contacted by /kbin instances. I don't post this to create division between communities, but I do hope that I can draw awareness to what's going on here. Defederating /kbin instances entirely would even be better than arbitrarily denying access one-way. This said, we should all attempt to maintain a good-faith interpretation until otherwise indicated by the Lemmy developers. It's possibel that this is a firewall misconfiguration or some other webserver-related bug.

Relevant comment from me (#354 - [BUG] Critical errors/failed messages during messenger:consume)

Edits:

Yes, people have already tried reaching out to the Lemmy instance admins in their Matrix room with no answer.
Someone has posed a question on Lemmy.ml about the block here: https://lemmy.ml/post/1563840

(page 2) 50 comments

sorted by: hot top controversial new old

[–] static@kbin.social 6 points 2 years ago (1 children)

Any news on this? It's till broken.

load more comments (1 replies)

[–] tal@kbin.social 5 points 2 years ago* (last edited 2 years ago)

If this continues, my instance may need to defederate from Lemmy.ml.

That probably isn't the right fix for the long term, because otherwise it leaves kbin vulnerable to being DoSed by another instance intentionally returning 403s, or breaking down if something goes wrong with a lemmy or kbin instance that causes it to throw errors for totally innocent reasons. Kbin should be fixed to handle getting 403s reasonably-gracefully.

EDIT: Also, might be a good idea to check lemmy's handling of getting 403s as well for the same reason.

EDIT2: I don't know if lemmy/kbin have any kind of test code to test how well they deal with federated servers malfunctioning, but my guess is that using one set of tests for both would probably save effort.

[–] melroy@kbin.melroy.org 3 points 2 years ago

They also do not sent POST / updates to my /f/inbox instance anymore. Lemmy.ml seems to activity ban Kbin instances. Which is very bad. I really hope this is not on purpose..

[–] NotTheOnlyGamer@kbin.social 3 points 2 years ago

Okay. So defed from them and stick to Local as default.

[–] PabloDiscobar@kbin.social 3 points 2 years ago

Check the instance list of Lemmy.ml, many seems to be missing version numbers. I don't know if it is relevant.

[–] dedale@kbin.social 2 points 2 years ago (2 children)

It's possibly an overreaction to the bot problem.
People started defederating suspicious instances, but what exactly count as suspicious is up for interpretation.
It's also very possible that was the point of the bot signups all along.

And on a relatively unrelated note, splitting the already minuscule fediverse, will kill any chance for it to become a real alternative.
Even if Lemmy's dev political views can be outrageous to some people, defederating them would be the beginning of the end imo.

[–] Gull@kbin.social 4 points 2 years ago (1 children)

Outraged feelings aren't the problem. Nobody is complaining about defederating Nazis. Defending and lying about Stalinist atrocities is morally no different from defending and lying about Nazi atrocities. If you let Nazis and tankies overrun your communities they won't be a "real alternative." Just like with Nazis, tolerating intolerance is intolerant.

load more comments (1 replies)

[–] Pamasich@kbin.social 3 points 2 years ago (1 children)

The issue is, it's only "kbinBot" and variations of that that don't work. If you just use "bot" itself, everything works fine. So it's not just an overreaction to the bot problem, unless all bot instances impersonated kbin.

The more likely answer is that lemmy.ml wanted to exclude kbin users from participating, but without actually limiting the freedom of their own users (which defederation would do).

And on a relatively unrelated note, splitting the already minuscule fediverse, will kill any chance for it to become a real alternative.
Even if Lemmy's dev political views can be outrageous to some people, defederating them would be the beginning of the end imo.

The current situation is misleadingly confusing to the average user and kbin moderators can't do their job properly.
I don't see how defederation, especially when temporary until the issue is fixed, harms anyone when we already can't interact properly anyway. I think the current situation is more harmful. Imo this sounds like the kind of situation defederation exists for.

load more comments (1 replies)

[–] jerome@kbin.social 2 points 2 years ago

and THAT is the end of federations.

[–] DarkThoughts@kbin.social 2 points 2 years ago

I think I had similar issues with one of the mobile clients using my Beehaw account, whenever I tried to write a reply I'd get a 40X (not sure which one exactly) error. I didn't pay attention to the server the post was on though but Beehaw being still on the .17 version might mess with other instances & clients in weird ways.

[–] sharkfeek@kbin.social 2 points 2 years ago

I've noticed this too. While I can post on a lemmy.ml community from kbin, I can't see it show up on my lemmy account.

[–] jerome@kbin.social 1 points 2 years ago

If you guys need a United Nations of sort, this is going to get messy.

[–] Rnway@lemmy.sdf.org 1 points 2 years ago (1 children)

Well, checking this post from my Lemmy instance (lemmy.sdf.org), it appears to be in sync with what I see from my Kbin instance (fedia.io).

Does that imply that whatever issue was in play here has been fixed?

load more comments (1 replies)

[–] cnk@kbin.dk 1 points 2 years ago

Just confirmed the problems by running the curl commands locally.

load more comments