Currently, almost anyone in the Fediverse can see Lemmys votes. Lemmy admins can see votes, as well as mods. Only regular Lemmy users can't. Should the Lemmy devs create a way to make the votes anonymous?

There is a discussion going on right now considering "making the Lemmy votes public" but I think that premisse is just wrong. The votes are public already, they're just hidden from Lemmy users. Anyone from a kbin/mbin/fedia instance can check out the votes if they are so inclined.

The users right now may fall into a false sense of privacy when voting because the votes are hidden from Lemmy users. If you want to vote something and not show up on the vote list, please create another account to support that type of content and don't tell anyone.

you are viewing a single comment's thread
view the rest of the comments

[–] Redjard@lemmy.dbzer0.com 2 points 3 months ago (1 children)

In my case I would like them to be private, but currently they are not. I don't think it is good to try to hinder the visibility into a fundamentally transparent system.

I don't see a technical way to make votes private either, that doesn't prevent bad actor instances abusing the vote system. As an admin of an instance I could just add 5-10 votes to all of my interactions whenever I feel like it, and noone would be able to tell it didn't come from legitimate users on my instance. The accounts of vote origin are needed as proof, hence moderators on lemmy having access to them.

Do you perhaps have any idea how this could be accomplished?

[–] BentiGorlich@gehirneimer.de 2 points 3 months ago (1 children)

You cannot make votes completely private, one instance has to have the authority over which votes do exist. This instance should be the origin of a post or comment.

At the moment it works like this: you upvote a post, this upvote gets send to the author of said post AND the magazine and that magazine then broadcasts your upvote to all subscribers of said magazine.

I could imagine that the process looks a lot different: you upvote a post, this upvote gets send to the author of said post, the author of the post then sends an update to the magazine saying how many people have now upvoted their post and the magazine then broadcasts this info to every subscriber of the magazine.

With that you would of course have new limitations concerning moderation and maybe there are trust issues regarding the correct reporting of that upvote count, but only the author of the post (and their instance ofc) could technically know who upvoted their post. As in everything here this is a compromise and whether the gained privacy is worth the other limitations, I don't know

[–] Redjard@lemmy.dbzer0.com 2 points 3 months ago (1 children)

This would solve some of the problems. If only 2 instances know about the votes, post instance and sublemmy instance, you can reasonably expect to get most instances to never release that info. It would allow either the sublemmy or post instance to manipulate around in the votes, but most manipulation would be detectable by the respective other instance.

It would open the door however to manipulating around with internal posts made from the instance in a sublemmy on the instance. And it would allow the post instance to drop votes selectively, though I think that is possible currently all the same.

Votes being sent to both the sublemmy and the post instance simultaneously would make manipulation a lot harder. And for cases like internal posts, you could add another involved "judge instance" that receives the vote details directly from source, and is merely there to confirm the total. Instances that hand out non-independent "judge instances" could be labeled as untrustworthy in the lemmy community.

So you end up with a list of instances per post that votes are reported to, to which you add the post instance, sublemmy instance, judge instance, and maybe some more.

In terms of implementation, I think the activitypub protocol needs an origin for votes, right? I would say an instance can just report the votes coming from a stock of obviously fake accounts, like "masked_upvote_1" to _999999 ... and "masked_downvote_1" to _XYZ.
About the votes, I am not sure. It could be done as a lemmy-internal feature where lemmy instances and other instances knowing of the lemmy protocol send the info to all the relevant instances, while any votes from external instances only arrive at I guess the post instance and that then forwards it on to all other instances. This way the checking doesn't work for software unaware of that lemmy specific vote implementation, but everything is still compatible.

You could then even for those lemmy-external votes add an interface on the judge instance, that would confirm via pm if your vote has arrived.

Do you think this could work?

[–] BentiGorlich@gehirneimer.de 2 points 3 months ago

We can look at PeerTube for an example of a system that could be shaped into what I meant: when you look at a post (video) from peertube it links lists for likes, dislikes and shares (so basically upvotes, downvotes and boosts). These collections contain a totalItems property, but also list the peoples identities, but just imagine that it wouldn't be there. When a user now likes the video, the creator of the video now sends out an Update acitivity to all subscribers. Now all subscribers can update the counts for likes, dislikes and shares. Only the "home instance" of the creator account knows about all votes, nobody else does, but nevertheless everybody else can now how many likes, dislikes and shares there are.

If we compare that to mastodon the first part of the statement is still true:

Only the "home instance" of the creator account knows about all votes, nobody else does

But that means that most instances just show 0 likes for most of the posts, because your instance only knows about likes originating from your instance...

As for your proposition: I couldn't follow for some of it. However I think the risk of an actor abusing the creation of fake accounts and fake upvoters is not really a risk, that is what defederation is for... I would argue very much agains a lemmy specific protocol and some judge instances simply because then big instances would just have pretty much all the data again and it would definitely hurt interoperability because lemmy devs can then just take the easier route instead of implementing something according to AP spec