p3x.deThe Voting Quota has ruined my workflow
So, I used to vote on posts constantly—not really to give karma, but as a quick way to mark them as read to get them out of my feed. It was perfect: a single click, much faster than actually opening the post. But now with the new voting quota in place, I can’t do that anymore without hitting the limit. According to discussions on the instance, the quota was implemented to limit voting activity, and it’s already affecting users who vote frequently.
The “Hide posts I’ve interacted with” setting is still there, but it relies on that interaction happening . What am I supposed to do now? Opening each post to mark it as read is significantly slower. Is there another way to mark posts as read in bulk that I’m missing, or is this just how it’s going to be now?
Share on Mastodon
Share on Reddit
Share on WhatsApp
I don’t know the back end situation, but I imagine, all other things being kept the same, this change maybe makes a low single digit effect on bandwidth.
I would disagree that this a problem at this scale. I would argue unlimited voting is a boon at this scale. It makes the threadiverse more “alive”, and encourages people to post and comment more.
At a large scale, I could see unlimited voting being a concern for bandwidth, but at that point the threadiverse is “alive” enough to sustain itself (and a discussion could be had then).
For a thought experiment, instead of limiting the top (x)% of voters, instead let’s eliminate them. What % of total voting is lost? Based on the numbers in your post a few days ago, 0.12% of people average over 240 votes a day and account for 6.43% of total votes. Removing them, you lose ~6.5% of activity. Doesn’t seem like much. In reality though, it’s going to make everyone who votes ‘a lot’, vote less. My guess a 15% drop in votes. That 15% less encouragement to people to keep posting and commenting. That may not mean much at large scores, but removing the single upvote someone gets for their effort contributing can/has killed people’s motivation to keep contributing (personnel experience).
I imagine many of the people who vote a lot also post and comment a lot too. So your probably going to lose some non negligible % of posts and comments too.
The threadiverse MAUs is holding relatively steady (+/- 10%) over the last year (not great, not terrible). Now start decreasing activity by 10-20%. Seems like a recipe for a downward feedback loop to me.
Also, something to consider, those heavy voters are probably the platform’s most enthusiastic users. So, in essense, you’d be muzzling your best supports to solve a theoretic future problem.
Also, to note, I couldn’t encourage your contribution to the discussion (upvote) in the hopes you’d be encouraged to do so more, because I can’t.
A final thought/critique, why not ask the heavy voters why they are heavy voters? You could find people like OP who need to learn about a feature (mark read on scroll) and after directing them to that, developers could work on UI changes to encourage people to use that feature (rather than limiting everyone).
To your other comment about your prior post:I’m aware of the post and the discussion in it. I participated in it and had a nice discussion with anon6789@lemmy.world (Superbowl community mod). I think OpenStars and Squirrel shared similar sentiments in that post.Edit: I only saw the notification of your other comment and thought you responded a second time to my comment in this thread.
That’s a partial picture of what’s happening. The other part is the other activity (comments and posts):
I am missing the data of Piefed.social for 2026-07-07 (but that seems to be the worst weekday for the previous week so probably not going to help that average).
Overall, it seems like piefed.social has less packets becuase there’s less activity overall (my previous comment’s point).
It does seem piefed.social has had a spike in DAU since the update, but that seems to be falling off relatively quickly:
That graph is from a testing instance which has no users and only receives federated content. So the traffic shown there is only from federation.
I’m not sure I understand, can you provide more context?
You provided network usage for an instance that doesn’t have internal activity to show that implementing user activity changes (for an instance that doesn’t have users) decreased network usage?
Or is this only federated traffic from piefed.social? In which case, it seems, it would accurately reflect the activity of only piefed.social users. Which wouldn’t go against my point (neither interpretation really would). Is there a different way I should be interpreting your comments?
The testing instance is not a source of traffic so the quota would have no direct effect on it. The savings there are a result of what’s happening on other instances.
I’m showing that the vote quota reduced federation traffic for the whole threadiverse by 30% to 50%. What’s happening there is lemmy.world, etc, where all the communities are, are sending less votes to everywhere (including to my testing instance). It’s the community hosters that send copies of the votes to everyone, not the instance hosting the voter.
This is a huge win, especially for instances that host a lot of communities like lemmy.world, sh.itjust.works, etc.
So looking at Piefed.world (on piefed version: 1.6.27):
Sh.itjust.works (Lemmy):
It would seem you need to normalize the packet rate for user activity to get an accurate picture. It should show a slight decrease of packets per active user (assuming same activity level), like you want and I said originally. But, it seems, the large decrease in the posted traffic graph is correlated to a large decrease in activity (posts and comments).
Piefed.social posts decreased 61.97%, and comments decreased 53.58% over the same period (much higher than a piefed instance that hasn’t switched and a Lemmy instance). So, I don’t think we should call this a “huge win” and would like to reiterate what I’ve been saying, the possible network stress reductions are not worth the downsides of limiting people (at this scale).
To me, you seem to be ignoring what I write and to repeat roughly the same thing over and over. That’s fine to do, just please let me know so I can stop responding (it’ll just save me and you some time).
Edit: formatting, and a word change
What’s up with OP’s votes anyway? My instance shows exactly 1 vote in the database, which is a bit of a mismatch against the original question?! But they’ve been here for a long time.
I’m confused on your question.
Are you saying the post only has one upvote (I see 14 up and 1 down?
Or are you saying your database only shows them as having used 1 vote? It’s a “daily” vote limiter so maybe it reset? Also, they aren’t on your instance so you may not be federated with everywhere they used their votes.
Or are you asking something else?
Sorry, I meant their outgoing votes. The post_votes table on my instance contains one upvote for the user account (this post’s self-upvote) and no other votes. No post_reply_votes either. But it should store data from the last 6 months. That could be due to perspective. But I don’t see any upvotes on piefed.social either. So I’m a bit confused since OP writes they hit the limit. Did they talk about a different account? Did the votes we talk about somehow get dropped? Or are we talking hypotheticals here and it’s been more than 6 months since they voted?
No worries. Appreciate the clarification.
That does sound weird. Could be a different account. I believe the servers only store the last like 3000 votes and drop the older ones (my votes last about a week). So, maybe something with that. Maybe a Piefed.social admin removed them because they considered them invalid or wasteful.
I think we’d need to ask a piefed admin or OP to get a better idea of what happened and why.