A post on kbinMeta states that “Lemmy.ml is blocking all inbound ActivityPub requests from /kbin instances.” More details here, but the theory is that – rather than defederating – lemmy.ml returns a 403 ‘access denied’ message in response to any inbound requests from a user agent with “kbinBot” in the string. Upvotes, comments, and boosts don’t seem to be going through. However, it appears that lemmy.ml still federates information outbound to kbin instances.
I’m wondering if anyone here knows what is going on and why it might be happening? Federation between Lemmy instances and Kbin instances seems to be a selling point for both, so I’m sure others using both services are curious as to what’s going on.
The linked post dismisses the v0.18.0 upgrade as a possible cause, but appears to do so without evidence and it’s by far the most likely explanation.
Whether the fix has to happen on the Lemmy or the kbin side to restore compatibility is an open question, but I don’t see any evidence of anything beyond a normal upgrade that broke an untested cross-app interaction.
I think 0.18 is very coincidental as well. My posts hard cut off on kbin 3-4 days ago, which is roughly the time that 0.18 came out. The problem is that I’ve posted things on beehaw which don’t end up on kbin, and beehaw is still running 0.17.4.
As I was looking into this stuff I’ve noticed that edits don’t seem to be federating very well between my server and beehaw. I hope there’s a more deterministic way to make sure that every federated server has everything it should, instead of just getting “most of it” and calling it good. (I don’t know anything about activitypub so maybe this is already baked in and we’re just failing on implementation)