this post was submitted on 22 Jun 2023
171 points (98.9% liked)
Lemmy
2172 readers
57 users here now
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to [email protected].
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can't aggregate them internally, anyway. You need to be able to know if someone already voted on something.
I think activitypub needs to be extended so that the likes and reduces only need to be sent to the host of the content, with federation then being told just the aggregate number. Then the only servers that need to know identity of votes are the host server (necessary to ensure nobody can multi vote) and optionally the server the user voted on (could just relay the information to the host server and not store it locally, but then it'd be harder to tell what you've already upvoted -- could use local storage but I think lots of people use social media on multiple devices).
I don't quite follow this. It might be a slow query with a full scan, but you could select on user-id, join post-ids with community-ids, and aggregate how a user votes in various communities, or do an export that joins votes and posts to analyze for word-clusters they up/down or whatever.
I was a bit surprised to see that it doesn't already aggregate at the browsing server. You could just queue up votes for a minute or 5 and say "post-123 got 12 upvotes and 2 downvotes in the last 5m".
I think they mean you couldn't exclusively pre-aggregate it to a vote tally on the post record and not track it per user. It must be tracked on a per-user per-post basis (in some way).
Ah fair. Assuming you have DB access to do this at all, you ignore the post-ids or join them to other tables to do all kinds of stuff.