SLRPNK recently received a registration request for @CommunityBoost – the bot for Lemmy Community Boost, which we’ve denied.
What is Lemmy Community Boost?
Lemmy Community Boost (LCB) is a system written by @iso, admin of lemy.lol. The purpose is to put new communities into the “All” feed of more Lemmy instances. All SLRPNK communities appear in SLRPNK’s “All” feed, but SLRPNK only requests content from a remote community if at least one of our members has subscribed to that community. If no-one on SLRPNK has subscribed to a remote community, then no-one will see posts on that remote community in the “All” feed.
LCB seeks to change this by creating a bot account on SLRPNK that subscribes to every new community on instances that have been pre-screened by Fediseer, a Fediverse Web-of-Trust system maintained by @db0 of lemmy.dbzer0.com (we are members of Fediseer.) The goal would be to make new communities more easily discoverable through the “All” feed, and in theory easier and less discouraging to grow.
As of this writing, more than two dozen instances have registered a @CommunityBoost user, including midwest.social and lemmy.blahaj.zone. More than a handful have either not registered or declined, including lemmy.dbzer0.com, lemmy.world, and beehaw.org. LCB keeps a roster at https://boost.lemy.lol/ with up to date information on participating instances.
We’ve decided to join the latter group for now. Our concerns fall into two categories.
Locally flavored All tab is a feature
While one might expect the “All” tab to act as the Threadiverse firehose, when visiting multiple instances to find a home, I found clicking on the “All” tab gave a short-hand of the kind of community hosted by the instance. Whatever the official intention for the tab, narrowing it to communities your fellow instance members find interesting is an imperfect but very efficient method of algorithmic suggestion without invasive tracking and click analysis. Perhaps future UI renaming it “suggested” with an alt-text “posts from communities chosen by your instance” would make the tabs’ behavior more intuitive.
This unique “All” tab behavior expresses itself most noticeably on smaller instances. These are also the instances whose communities are likely to be most greatly affected by LCB, meaning the smaller instances would be forced to make a trade if all other things stayed the same. But even keeping the previous functionality and renaming the “All” tab, creating a “Firehose” tab may still be an anti-feature.
Hopefully invisible to most users is the battle that admins and moderators fight against spam and abuse. The tools native to Lemmy and Kbin software are less than adequate for the job, and admins coordinate efforts across instances on matrix and XMPP to fight the flow. While some attacks are obvious, others are confusing and subtle. Since most instances allow unsupervised community creation, allowing anyone who creates a new community to broadcast that community name and content across the Threadiverse could open a new vector for spam and abuse.
The vast majority of communities on Lemmy are abandoned, created in a flurry of activity 4 months ago. There are more people willing to create communities than there are people willing to contribute posts to them, or even stick around and moderate them. The communities on lemy.lol seem to follow this pattern. This is the problem LCB is supposed to solve, but is the issue that people can’t find these communities, or that there aren’t enough people with free time available to keep them alive in the first place?
Some communities in the Threadiverse have reached a critical mass and feel vibrant, others feel like they are on life support – supported by one or two regular contributors, while many are verifiably dead. LCB doesn’t seem like it would bring new users to Lemmy, only redistribute where existing users spend their time. Is this what Lemmy needs, or would it be more prudent to prune dead communities and encourage consolidation of scarce volunteer resources into a smaller number of vibrant and growing communities?
Concerns about performance
While the number of Lemmy instances grows linearly, the connections between them have the potential to grow geometrically. This leads to concerns about software efficiency and hardware performance.
Take the example of a Threadiverse ecosystem with ten instances, each with 100 communities each. A bot user would bring the remote subscription count to 900 for each of the instances, for a total of 9,000 database entries. For each instance, the traffic would be expanded to a potential 9,000 community updates every update cycle, for a total of 90,000 community updates across the Threadiverse each cycle. There are significantly more than ten instances, and if you run the hypothetical example again with 1000 instances, you can see how database requirements and cross-instance traffic can get out of hand.
A firehose style “All” tab could limit the development of smaller instances by requiring them to handle the kind of traffic and database churn only seen by the largest Threadiverse instances. The financial and technical burdens could create a barrier to entry that may have the opposite effect than what was intended.
Caveats about criticism
I’m really impressed by the work @iso put into this tool. The Threadiverse needs more developers to help solve its many problems, and I’m grateful he was willing to write code and share a solution.
As an admin, moderator, and community contributor, I recognize that starting new communities and keeping them alive takes work, and welcome tools that make those activities easier. I think this tool was developed with good intentions.
These concerns are based on our intuitions about the needs and limitations of our instance, and our vision for the Threadiverse. While I stand behind the concerns, I admit they are not the result of a rigorous study. We reserve the right to change our mind if the benefits of LCB become more evident, but we’re planning to sit out the experimental phase.
Yes, bot accounts will be subscribed to that community until a normal user subscribes.
And yes again, if there is no active bot on SLRPNK, then it will not change SLRPNK “All” tab.
The number of subscribers will increase up to amount of bots but as I said, it will unsubscribe when a normal user subscribes. So it will neutralize with time.
Edit: It follows synchronously with first request so it takes time. I should’ve made it async but no time unfortunately. As you can see from the record, that community federated with only 2 external instances besides 24 other ones.
Yep, !documentaries@slrpnk.net jumped from 40 to 61 subscribers. Nice work.
I don’t think that particular function is harmful to SLRPNK in LCB’s current state of adoption. @poVoq has a better handle on the software and hardware limitations than I do.
I think it would be nice if the function had two additional features:
We have a lot of great contributors from the Threadiverse, and Slrpnk wouldn’t be the same without them, but also nearly 100% of the abusive users come from remote instances too. It’s very noticeable when our posts trend in other instances’ “All” tab. I would choose to leave the decision to individual moderators whether they want to make that trade-off, since they deal with the brunt of the consequences.
I realize that once someone from a remote instance subscribes, ‘the cat is out of the bag,’ and the community will be in the remote’s “All” feed forever – but removing the community from instance “All” tabs where no-one has subscribed yet and preventing circulation on new instances that join LCB later can limit further damage if the moderator has had too much.
Adding the option to remove communities is probably most ripe for abuse unless some kind of user authentication feature is added. I realize this adds significant complexity to the app. It’s a kind of shitty ask, as we’re essentially leechers who don’t seed at this point (to use a filesharing metaphor.) But I do think it would make it less intimidating to try, and mods on instances where it is enabled globally could choose to opt out as well.
I wish Lemmy had OAuth so that I could and would like to do authorisation easily, but at the moment trying to do that is more difficult than building this tool.
I’m thinking of a standalone authorisation library like Fediseer doing. If I implement it, I can develop LCB much more easily.
By the way I see your concerns. Unfortunately the federation is like the wild west right now and there’s a chance the LCB would make it more complicated. I’ll try to make that doesn’t happen.