You Should Know

It is only shocking if the expectation was set that your votes are private. If you wanted to avoid linking an identifiable account with their votes then you could use a de-identified user account to track a user's votes.

You could to perform deterministic hashing prior to persisting a vote to ensure that those looking at the database can't go backwards to find the specific users who voted on a post. But any service that knows the salt and hashing algorithm can start with a user account and determine that user's voting history.

This allows you to track up/down votes per user without allowing over-priviledged DBAs or malicious actors from poking around voting histories of identifiable users.

Another way to be more private is to only federate upvote/downvote count, instead of the detail of the upvote/downvote. This is not only lighter but more private. When the count needs to be updated just broadcast the new upvote count.

But I see why they want to do it the current way, as it is more aligned with activitypub protocol, and allow other platform like mastodon to participate without problems.

I cannot think of much problem in implementing a "hidden upvote system" in activitypub. Basically, it will work like this:

• user on instance A upvotes a post in instance B: instance A tells instance B the user upvoted the post, but not anyone else.
• instance C trying to fetch a post from instance B: B will only communicate the upvote/downvote count, but not the detail
  • if instance C is not a threadiverse instance (like mastodon) it will show "xx number of upvote from B is hidden."

Remove voting! End this dumb mob mentality!

It's the only way to avoid double voting from the same account or to remove the reverse vote if one changes one's mind and votes the other way.

A better way is to store only who has voted. No need to store how they have voted.