this post was submitted on 05 Nov 2023
19 points (95.2% liked)

Voyager

5576 readers
4 users here now

The official lemmy community for Voyager, an open source, mobile-first client for lemmy.

Download on App Store

Download on Play Store

Use as a Web App

Download on F-Droid

Rules

  1. Be nice.
  2. lemmy.world instance policy

Sponsor development! 👇

Number of sponsors badge

💙

founded 1 year ago
MODERATORS
 

It looks like this was a larger decision from the lemmy development community in an attempt to eliminate karma farming. They say it’s psychologically damaging, and as someone who looks at them a lot, they may be right.

Here’s a GitHub thread discussing it where our Voyager dev weighs in:

https://github.com/LemmyNet/lemmy/issues/3393#issuecomment-1779400639

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 1 year ago (1 children)

Well each user is running an app, they can each computer for themselves at the very least

As far as other users go, when you open a user and you see their comment history, the app can certainly sum up the votes of the comments displayed without doing any extra queries. That ratio may be useful to identify trolls, or good actors

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (1 children)

If each user is caching it, that would be even more resource intensive on the API than if the app was storing it somewhere and serving it to users. It would mean each time that a user clicks on another user’s profile for the first time, the app would need to pull all of their comments in order to calculate their score. If it were cached on servers at the app level, then you and I requesting the same user profile in a short period would only require api requests to pull all of that user’s comments once.

Storing it centrally means one repository making calls for scores. Storing at the app level means there are N repositories for N apps making calls. Storing it at the install level for each app instance means that you’d have astronomical amount of calls to the API to calculate this number. It would be incredibly expensive to do it that way and could be a behavior that may slow all API response to a crawl.

[–] [email protected] 1 points 1 year ago (1 children)

You're making this more complicated than it needs to be.

The simple naive approach would be every time the app sees a post, it can memorize the current score for that post locally. For the user of the app, that should be all their posts right? This doesn't need to be accurate broad strokes are fine we don't have to catch votes that happen after we've last seen the post

For other users we look at, we could just tally the posts we see when we open the user profile which would be a few that get dynamically loaded I think five or six. That should give us trend data.

We don't have to engineer anything more complex.

[–] [email protected] 3 points 1 year ago

I really think you are grossly oversimplifying the problem.

When I click on any user’s profile, I’m seeing content from a lot of posts that my app instance hasn’t seen before. Each user follows different communities and accesses the app at different times, so each user’s instance will only have data on the posts that they have clicked through when they are browsing. The score calculation that you are suggesting would vary wildly depending on how much overlap you’ve had with that user previously. 5 or 6 posts out of hundreds or thousands would not be enough to consistently see a valid trend.