• 0 Posts
  • 644 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle










  • 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.






  • 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.