lemmy
lemmy copied to clipboard
LemmyNet
Weighted Community Subscription for Feed Display
Requirements
- [X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
- [X] Did you check to see if this issue already exists?
- [X] Is this only a feature request? Do not put multiple feature requests in one issue.
- [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
Is your proposal related to a problem?
Currently, the number of posts displayed in the 'subscribed' feed on Lemmy is determined by the votes a post receives, which is proportional to the size of the community. This can lead to posts from larger communities overshadowing those from smaller, but more favored, communities.
Describe the solution you'd like.
Introduce a feature that allows users to assign a weight to each community they subscribe to. The number of posts displayed from each community in the 'subscribed' feed should be proportional to the assigned weight, rather than the number of votes a post receives. This would enable users to see more content from their favorite communities, even if they are smaller in size.
Describe alternatives you've considered.
An alternative solution could be to implement a ranked-choice voting system, where users rank their preferred communities, and the feed displays posts based on these rankings. However, this may not be as flexible as the weighted approach, as it does not allow for fine-tuning the proportion of posts displayed from each community.
I was considering this same thing yesterday. Here was what I had considered (if one of the devs can pitch in to say if my idea is viable, that would be sweet):
Rank = ScaleFactor * log(Max(1, 3 + Score)) / (Time + 2)^Gravity / (Subscribers + 10)^CommunityFactor
Let me break down this formula. The first part:
Rank = ScaleFactor * log(Max(1, 3 + Score)) / (Time + 2)^Gravity
is the sorting algorithm as it is now (obtained from Lemmy's documentation).
If we assume that there are two equivalent posts (ie, equal posting time, equal votes, equal likeability), but one is posted on Community A and the other is posted on Community B, we can start to see discrepancies in how the sorting algorithm works.
Let's assume that Community A has 10x the subscribers of Community B. In that case, then we can generally expect that 10x users will see the post on Community A, and it'll gain 10x more votes than the post on Community B. Hence, the post on Community B will be buried very quickly. This causes the user feed to be primarily posts from bigger communities.
Since we can generally expect that, all else being equal, Community A will receive 10x more views/votes than Community B, we can try to normalize that by dividing the rank by the number of subscribers of that community. If we do that, then then Community B's post will now be on equal footing to Community A's post, even though Community A has 10x more views.
I'll add 10 to the subscriber count in the ranking algorithm, just so it's impossible to divide by 0. I don't expect that this will significantly affect the ranking.
With this modification, small communities and large communities will be on perfectly equal footing in the ranking algorithm. (ie, a top post on a small community will appear in a user's feed just as often as a top post on a large community.) But this also means that there will be a lot more posts with few votes in the feed, even though they've been posted a while ago. Maybe this is the desired result, maybe not. But I'll add an exponential to the subscriber count, which I'll call CommunityFactor. This number should be between 0-1, where 0 makes the algorithm functionally equivalent to how the algorithm functions now. A CommunityFactor of 1 completely normalizes according to community size, and a CommunityFactor between 0 and 1 will weigh small communities slightly more heavily but does not fully make them equivalent to large communities.
My guesstimate is that CommunityFactor is probably good at 0.8-ish.
What are your thoughts?
