this post was submitted on 19 Aug 2024
693 points (97.5% liked)
Fediverse
28382 readers
1235 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is a very real problem right now. Admins that are on to it use the votes to identify swarms of users that follow each other around upvoting each other's spam/troll posts.
And that is still possible with pseudonymous tokens votes. You just end up banning tokens for malicious voting activity, and users for malicious posting activity. It's at best a very mild adjustment to moderation workflows.
How does this work? The community issues federates votes but with a linked token instead of a linked user? How do you track vote manipulation across different communities on different instances?
As far as I understand it all activity originates from the home instance, where users are interacting with federated copies of posts. The unique user token from a well behaving instance follows the user across the fediverse, allowing bulk moderation for voting patterns using that token. The only difference is that it is not explicitly tied to a given user string. That means moderation for vote manipulation gets tracked via a user's vote token, and moderation for trolling/spam/rule violations happens via their display name. It may be possible that a user is banned from voting but not commenting and vice versa. It's is a fairly minor change in moderation workflow, which brings a significant enhancement to user privacy.
Under activitypub, a lemmy community is kind of like a user (actually an activitypub group). When I post here with my lemmy.nz account to this lemmy.world community, lemmy.nz sends my comment to lemmy.world who then sends it to sh.itjust.works for you to see. The community is the controller of all interactions within the community. In this case, lemmy.world is the official source of how many upvotes this post has. And each vote is validated using the user's public key to ensure it actually came from that specific user - a standard part of ActivityPub.
So would lemmy.world assign a token for your votes? If your instance assigned the token, Lemmy.world would not be able to validate against your user's public key. If Lemmy.world assigns the token, it would only be valid in lemmy.world communities, as other instances would have to assign their own token. And both sh.itjust.works and lemmy.world admins could still see the real association.
Also, changing how votes work would break compatibility with other ActivityPub software (e.g. Mastodon could no longer interpret an upvote as a favourite, Mbin would't be able to retrieve any data about the votes unless they specifically changed to work in the Lemmy way instead of using standard ActivityPub).
Worst case scenario, there is an entirely separate, tokenized identity for votes which is authenticated the exact same way, but which is only tied to an identity at the home instance. It would be as if the voting pub is coming from user:socsa-token. It's effectively a separate user with a separate key. A well behaving instance would only ever publish votes from socsa-token, and comments from Socsa. To the rest of the fediverse socsa-token is simply a user which never comments and Socsa is a user which never votes.
I am not sure key based ID is actually core to AP anyway. The last time I read the spec it kind of hand waved identity management implementation.
Well hey, sounds like you might be able to help. Lemmy devs are actively soliciting opinions on lemmy votes, maybe you could have a say? Most of the comments are around "votes are already sort of public" therefore either a) make them actually public so we aren't pretending they aren't, or b) keep them hidden, a little less public is better than completely public.
Perhaps you can come in with a c) option to make votes even less public?
https://github.com/LemmyNet/lemmy/issues/4967
Maybe. I was kind of hoping someone else would run with this flag because I don't have a spare public GitHub account I really want to throw into this debate. I'm more likely to just implement it and then toss a PR grenade into the discussion in a few months if there's no other progress.