Introducing Lemvotes

I want to remind everyone that since users overwhelmingly don't want their votes snooped on (for good reason), we will never add anything like this inside lemmy, lemmy-ui, or jerboa.
While there's nothing we can do to snoopers making tools like this, it requires a lemmy server admin login.
If you know of servers which are giving admin access to this tool, let us know, so we can add it to our blocklist.
- That's reassuring to know. What I don't understand is why you have the /api/v3/post/like/list route. You say you don't want votes to be snooped on, but then you add an endpoint that makes it very easy for instance admins to do exactly that if they choose to? Also worth pointing out that the tool linked here wouldn't work in its current form if this route didn't exist.
  
  Read the issue above for why. Vote manipulation is a real problem, but making all votes public is not the solution anyone wants. Limiting vote viewing to admins and mods is decided on as the best of both worlds.
  Also that tool can only be used by specifically malicious instances whose goal it is to snoop and expose all votes. Those instances can and should be blocked.
  
  This is for admins to see easier vote manipulation. I think mods can see that on their communities too.
  For admins its like... they could literally just look into the database, so it doesnt make any difference. Mods in the other hand should rather not snoop around i guess.
  This tool just simplifies the process instead of creating an open federated instance yourself and see the votes.
- Maybe federation should be based on allowlisting, instead of allowing instances by default.

Can you like maybe don't??

I will describe how it works and the ethics of such a tool.
Where in this post do you describe the ethics of such a tool?
non-technical users believe that their votes are private, which is far from the truth. This attitude could potentially lead to harassment of Lemmings (yes, that’s what we Lemmy users call ourselves) for upvoting a particular post. Lemvotes makes it clear that votes are not private, which could help bring a more accurate picture of the way votes work on Lemmy to its users.
This is what needs discussion. It is this tool which will lead to harassment due to the way someone votes. And the threat or spectre of harassment will lead to the Chilling Effect, ie. self-censorship (of voting) to avoid harassment.
The chilling effect this causes will make communities even more like echo-chambers, as dissent will be pre-emptively squashed.
Without a tool like this existing, people have to go out of their way to find out this information (setting up their own instance, or finding someone who already does this surreptitiously). By making such a tool available to the lemmy community at large, you make it extremely easy for anyone to do this, and so the chance of harassment occurring is much higher.
You might think you're being clever, or on some kind of crusade to educate the uneducated. But actually your actions are making this (community-built) platform worse. Compare your actions to releasing a 0-day exploit for a security vulnerability instead of responsibly disclosing. It doesn't help, it just causes chaos until the people who do the actual work can figure out a solution.
Think about how your tool existing now changes the dynamic of Lemmy as a whole. Is it better, or worse? How would you actually solve this problem in Lemmy, instead of exploiting it?
- Kbin/mbin already surfaces votes, third party apps can easily show them as well. This is an intrinsic behavior of activitypub and people should know how easy it is to expose that data.
  
  We've opened up issues on other services many months ago about retaining user vote privacy, because lemmy users overwhelmingly don't want their votes snooped on.
- Compare your actions to releasing a 0-day exploit for a security vulnerability instead of responsibly disclosing. It doesn't help, it just causes chaos until the people who do the actual work can figure out a solution.
  This comparison is not fair at all. It's not like the devs are unaware of this. They could start by removing the API endpoint that lists a post's votes, but they haven't, which means they seem to think it's okay for the instance admins to snoop on votes if they so wish.
  
  Then couldn't that give instances free reign to start creating fake votes?
  
  As I understand it, ActivityPub-compliance basically requires that a vote is tied to an actor. Although, they could have made a dummy actor do it. Maybe they were worried about stopping vote manipulation?
- This is already a thing that happens currently. Some admins/moderators don't like being downvoted and ban people for "vote manipulation" because they vote on things in their feed.
  It is leading to exactly that, where people are worried that using the voting system as intended will lead to exclusion from participation in some communities.
  
  I've personally been banned from one community for downvoting too consistently.
- The easy solution is to stop engagement on Lemmy. Cool. Cool cool cool.
- This is what needs discussion. It is this tool which will lead to harassment due to the way someone votes.
  wrong. voting users are already visible through other services, like mbin. and the information is already there, those who are really interested are already scraping it, this just makes it more accessible and also serves as an eye opener
- The chilling effect this causes will make communities even more like echo-chambers, as dissent will be pre-emptively squashed.
  If only there was a tool that allowed you to host an instance on a federated network that allowed you to make your own community and control how the rest of the network can interact with it. Why has nobody built this???

Having access to information about who voted on a post would allow people to locate brigading1 efforts and detect bots spamming down/upvotes on posts. Currently, only admins can access this information, which makes it harder for users to report such behaviour to them.
Or provide the empire controlling most of the bots, extra ammunition to have AI determine a social credit score for everyone. Winner gets a free trip to El Salvador.
- I find this whole thing weird because some federating platforms (like mbin I think) already show voting users publicly
  
  I think they limit it to upvotes for normal users

Votes should be anonymous.
This is the first step toward monetizing Lemmy for multinationals.
- Votes should be anonymous.
  I tend to agree, but the fact is that they aren't anonymous. This tool just exposes the already-existing fact that Lemmy expressly does not guarantee anonymity for votes. The solution isn't to not for the poster to not publish this tool. Believe me, such tools already exist in private even if none other than this one are published. Publishing this one only democratizes access to that information. (~~And not entirely, I don't think. From what I'm seeing on the page, it looks like it still requires an admin account on an instance.~~ Update: Actually, I'm not sure if it requires an admin account or not. Either way, though.) The solution is (if it's possible) to make Lemmy itself protect voters' anonymity.
  The reason why instances know who has up/down voted things (rather than only keeping an anonymized "total" for each post/comment) is so it can prevent double-voting.
  Maybe instead of usernames, the instances could store/trade... salted hashes of the usernames where the salt is the title or unique identifier of the post/comment being voted on? It wouldn't be perfect, but it would allow the instance to figure out whether the currently-viewing or currently-voting user has already voted while also making it harder for anyone else to get that information. About the only way a tool could tell you exhaustively who had voted if that were how things worked that I can think of off hand is to try every username on Lemmy one-by-one until all the votes were accounted for.
  (Of course, malicious instances could still keep track of usernames or unique user ids who up/downvoted, but only on the instance on which the vote was cast. Also, one downside of this approach would be increased CPU usage. How much? Not sure. It might be trivial. Or maybe not. Dunno.)
  And there may be much better ways to do this. I haven't really thought about it much. I also haven't checked whether there is an open ticket asking for improved anonymity for votes already.
  (Also, full disclosure, all of the above was written after only an extremely brief skim of the linked page.)
  (One more edit. Something IHawkMike said led me to realize that the scheme I described above would allow instances to manipulate votes by just inventing hashes. Like, grabbing 512 bits of data from /dev/urandom and giving it to other instances as if it was a hash of a username or user id when, in fact, it's not a hash of anything. Other instances wouldn't be able to easily tell that it wasn't the hash of a valid user id. I haven't thought how to go about solving that yet. Maybe if it occurs to me, I'll update this post.)
  
  Yep this is exactly right. Too many people are unaware that their votes are not anonymous on Lemmy and blocking the public tool only helps the bad guys who already know this. I've always thought this was a major weakness in Lemmy but I don't have a solution myself without some other major drawback.
  I think probably votes should be anonymized or batched between servers so that only your instance's admins can see individual votes and you just have to trust the instances you federate with that they aren't pulling any shenanigans or otherwise defederate. That's not an easy problem to solve, but it's not like it's not currently possible to manipulate votes with a federated server, it would just be harder to detect. Regardless I think the need for privacy wins here.
  
  Maybe instead of usernames, the instances could store/trade... salted hashes of the usernames where the salt is the title or unique identifier of the post/comment being voted on?
  I didn't have time to reply earlier, but I was thinking the same thing, except with the extra step of replacing the username with a unique user identifier randomly generated at signup by the user's instance and kept secret.
  I wonder if there's a way to prevent people from even knowing that two different votes came from the same user.

FYI it fails to fetch votes if you don't include https:// at the start.
- Thanks for the heads up, will fix it asap
- a zero-day(ish) flaw caught via Lemmy 🫣
  edit: i was just kidding, btw

Appreciate the effort, but
Failed to fetch votes
- Which URL did you use?
  
  Just plucked the URL from my own latest post to test: https://kbin.earth/m/vinyl@lemmy.world/t/1255550
  According to mbin, that's the original post URL, but does the site need a different format? Because trying another random post from my timeline I get a list of votes: https://programming.dev/post/29327147

Honestly surprised you're able to get lemmy votes without an admin account, I thought that data was restricted to instance admins.
- it's literally explained in the post that it uses admin credentials
  
  Huh, I missed that when skimming through the post and source code
  I am considering implementing my own ActivityPub server to remove the dependency on a Lemmy server to get votes,
  I saw that part and misunderstood it as if he didn't run an instance.
  Thanks for pointing it out!

upvoted for cute cat someone tell me what the articles about

Worked for me, but this needs a lot of development to be a useful tool for analysis, and maybe a browser extension.
- Which features would you like to see in Lemvotes?
  I have no idea at all how to make a browser extension, I can try I guess but that's of lower priority, as I will try to have it use activitypub directly.

I have been working on Lemvotes, a tool to check who voted on a Lemmy post. In this blog post, I will describe how it works and the ethics of such a tool.