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!