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
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).
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.
defederation, especially when temporary
It will create ill will. Perhaps first have kbin’s instances admins try to contact the dev.
And if they’re unresponsive after a reasonable time then assume bad intent. Or maybe call them out publicly?
If Lemmy’s dev them are actually trying to shadowban kbin, yeah fuck em, it would be evil behaviour.
But that would be a serious setback since lemmy has metcalfe’s law running for it.
I think dissolution is one of the most obvious and dangerous vectors of attack on the fediverse (along with flooding and the classic embrace and extinguish), so we should keep that in mind.
Not to let paranoia take the better of me, but there are huge financial and political interests rooting against a free, transparent social media platform.