(What makes this an unpopular opinion is that I’m basically advocating for jettisoning an entire Fediverse platform rather than just riding out the rough patch.)

I admin a Lemmy instance, and the amount of spam we get from Kbin and have to deal with is absolutely insane. Every morning I have to spend at least 15 minutes cleaning it up: responding to reports, banning accounts, purging posts, and pruning the images. And it’s more of that all through the day, just in smaller bites.

Many times I’ve toyed with the idea of de-federating Kbin instances completely, but I don’t want to cut off interactions with their legit users. The legit users are not the problem and are very much welcome.

Side note: If you’re reading this and thinking “What Kbin spam?”, then you should reach out to your instance admin(s) and give them a big ‘thank you’. The spam from Kbin is not just a “me” problem.

The underlying issue is that Kbin mod actions do not federate to Lemmy. At all. The mods of their magazines can (and probably are) doing a great job cleaning up spam, but once that spam goes out, it’s a one-way trip to Lemmy and completely up to the instance admins to deal with. For comparison, on Lemmy, the community mods can remove the spam which will then issue a removal action on instances that received it via federation.

I’ve tried various ways to unsubscribe and remove Kbin communities on my instance, but the “unsubscribe” doesn’t seem to be honored by Kbin, either. So I’m stuck receiving content that’s 90%+ spam and having to deal with it every day with no end in sight (barring de-federating Kbin completely). The only thing that sort-of works is hiding the Kbin magazines on my end, but that just hides the spam, too, and I’m still stuck storing it on my system.

So yeah, life for Lemmy admins would be easier if Kbin users would make the switch and I could just de-fed from Kbin without losing the good people.

      • rentar42@kbin.social
        7·
        1 year ago

        I think you’re underestimating how much work a proper fork of a (at least semi-popular) OSS product is. You need multiple devs with active time commitment to even have a chance of doing better than the original.

        IMO no, the solution isn’t to create a fork, but to find more “core-developers” to join in kbin to increase the bus factor. That’s not easy either (and needs cooperation by the current dev(s)), but it’s significantly easier than bootstrapping a whole fork.

        • reev@sh.itjust.works
          2·
          1 year ago

          I am almost certainly underestimating everything when I’m talking about dev stuff. Was a genuine question :) Was just wondering what the alternatives would be if he’s not accepting any PRs and doesn’t have time to find more “core-developers”. Would the project just die? I quite like kbin’s microblog Integration.

          • rentar42@kbin.social
            2·
            1 year ago

            I don’t know the details of this specific project, but assuming that it’s really like many other projects basically a one-person-show at the moment there’s IMO several possible scenarios:

            1. moderation federation doesn’t get fixed quickly enough, kbin instances get mass-defederated and the project effectively dies (some kbin instances and fans will stick around, but they will be a minority and effectively be little defederated islands)
            2. the main dev finds good co-devs and enough time to on-board them in a sane way despite his lack of time at the moment and they can develop and merge a fix for the defederation issue in time to avoid mass-defederation
            3. #1 happens but someone (apparently mbin, as linked elsewhere) forks the project and takes over as a successor and most kbin instances eventually switch over to mbin.

            All of these scenarios have happened to various projects at various times for various reasons, so it’s really hard to tell which one it is.

            Of course there’s also the chance that despite not having much time and not finding/adding co-devs the main dev finds just enough time to fix this issue and the project continues to limp along. That would basically just postpone the other three options IMO, since this is unlikely to remain the only major issue. Problems tend to happen with software.

            Edit: oh, and I forgot that it can also be a mixture of both of those: a fork exists, but the original project also continues and both just live on next to each other with slightly different goals/communities behind them. That’s not even necessarily a bad thing.

        • rentar42@kbin.social
          1·
          1 year ago

          I mean if the fork fixes it and the original doesn’t and enough of lemmy defederates with the remaining kbin servers, then they will have to reconsider switching or falling into irrelevancy.