I noticed that a lot of the communities that are hosted on there only have posts from a week ago. Thought they were just a bit dead, but checked on their original instance and saw they’re more lively than that it’s just not showing up on Kbin.
It seems to me that the simplest explanation is that kbin handles additional actions, such as user content boosting, and the AP structure is also slightly different. While Lemmy <-> Lemmy cooperate well with each other, kbin can cause confusion through erroneous server queries, significantly increasing the load. I have been working on reducing unnecessary requests, which was a result of migrating to a new server and discovering weak points. Work in this area will be continued to ensure that we do not harm each other primarily.
Have they told you protocol compatibility is the reason?
I ask because when you assume, you make an ASS out of U and ME. Which is a fun way of saying, while you have found an issue which should be resolved, you might complete the work and discover they had a different issue.
Secondly its important to remember while software engineers like to think they are super rational. They are people and people can have myopic views and giant egos.
Both of which can allow people to rationalize all sorts of weird and counter productive behaviour.
Have they told you protocol compatibility is the reason?
Nope, we don’t have any contact with each other. I simply associated it with the fact that both lemmy.ml and kbin were having issues handling the overall traffic at that time. That’s all I know right now.
Lemmy.ml blocks any kbin instance on purpose by blocking the kbinBot User-Agent
Why do they do it?
They did not answer to that question. But, lemmy.ml is run by the same tankies that develop Lemmy and also run lemmygrad so probably some tankie logic.
Like alexmitter said, lemmy.ml is blocking incoming requests from kbin instances based on the user agent, a text kbin uses to identify itself to the target server. So kbin can’t request any new posts or comments from lemmy.ml.
They aren’t formally defederating kbin though, probably because they want to give their users continued access to kbin magazines.
If I was Ernest I would configure Kbin to use a key/value map. Of instance name and a bot user id.
If instance request failures reach a threshold it which switch out the user agent to something new for that instance.
Perhaps you randomise it a little, perhaps use the lemmy id, etc…
My goal wouldn’t be malicious, more to mess with the lemmy devs. They can be honest an defederate from all kbin instances or spend lots of time quietly blocking them.
Viewing a different fediverse site on lemmy shows old posts for some reason
As far as I know, lemmy.ml itself is not blocking kbin requests, at least not on purpose.
But I will try to get some official information from one of the lemmy.ml admins.There were some issues with the federation of non-Lemmy instances in general.
Multiple issues caused these and affected incoming and outgoing communication.https://github.com/LemmyNet/lemmy-ansible/issues/106
https://github.com/LemmyNet/lemmy/issues/3354The latest Lemmy version 0.18.1, which was released yesterday, should fix most of the issues, but some instances still need some fixing on the nginx side.
