In addition to that, I guarantee you that meta and the like are already running data mining instances on here. Being publicly tied to votes is just more telemetry for the machine. I don't quite understand why people seem to think that is no big deal.
Who cares? Generating an infinite number of tokenized identities to facilitate ban evasion will just result in an instance getting defederated. This introduces no real risk as long as the instance is generally abiding by the rules.
Most of us here are fairly anonymous anyway. I dont think being able to add an additional layer of privacy to our activity is really a big deal.
Awesome! This is the exact stopgap implementation I was arguing for, and I'm surprised how many people kept insisting it was impossible. You should try and get this integrated into mainline Lemmy asap. Definitely joining piefed in the meantime though.
The rogue instance would still need fake users though. It would be very easy to see if you are getting votes from 300 unique tokens, but the instance only has 100 users.
Also the method I am proposing would simply be transparent in terms of user management, so if you are running core Lemmy, the only way to generate voting tokens would be to generate users.
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.
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.
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.
It will be extremely obvious if you see 300 user agents voting but the instance only has 100 active users.