Yes, after all other servers need this information in order to prevent double voting, you can’t just have servers sending each other information “somebody upvoted this” and also tell when servers are allowing users to vote more than once.
So upvotes and downvotes aren’t actually private, never have been, some servers may display them publicly even if most don’t.
It only needs to tell other servers the vote count, and the votes of people on that other server.
That may not be how it actually works, but that’s all that’s needed
Yes, but then you can have malicious servers sending fake numbers without other server operators being able to check whether this is at all plausible.
(It’s still possible for malicious servers to send fake votes, but server operators can see which users they are stated to originate from, then block that server if that looks like it’s doing that. At least that is my understanding.)
What do you mean “send fake votes”?
Or rather, who do you think should be responsible for identifying and blocking fraudulent votes?
And how do you reconcile votes that come from servers that you’ve defederated with? Should everyone have the same view of the post, or should people only see votes from servers that their server is federated with? What about votes from users you’ve personally blocked? Etc
I personally kinda think that the responsibility is on the server hosting the post, and that everyone should see the same (but anonymous) vote count, of which the hosting server is the single source of truth.
I’m not sure how giving every server access to the votes solves that.
The malicious server can make fake users to pump up votes. your server admin has to notice, then check the vote logs, then see what’s happening and defederate them. That’s pretty much what you described in your scenario, anyways.
But it also has to be defended separately by the admin of every server that has a user subbed to that community. Seems like a large burden to put on small-mid instance admins.
I’d be surprised if my server admin was really paying attention that closely to votes on communities I’m subbed to, right?
I have to admit I don’t know the view that admins get of how their server intersects the fediverse.
Yes, that’s happened before. They were sending a very large number of votes, so it was immediately obvious. Even a couple dozen from an unknown instance will be noticed, when an admin sees it and says “huh I haven’t heard of that instance” and when they look there’s nothing there.
There are plenty of ways to handle double voting without plaintext user strings. The fact that it’s done this way is just lazy and poor design and doesn’t actually do anything to prevent a rogue instance from vote spamming with fake users.
Hashing alone if it’s just usernames isn’t enough. Need something like keyed hashes, but then malicious servers can lie about numbers of votes.
Otherwise you need something ridiculously overengineered like public but encrypted logs of user actions and Zero-knowledge proofs of correctness mapping everything to a distinct existing user without revealing who it is.
As I mentioned in another post: for consistency is better to have each server count total votes from their own users, send a signed & timestamped message with the count to the host of the post being voted on. Then the host can display a consistent vote count to everybody that shows where votes are coming from without manipulation of external votes.
Each individual server can lie about its count, but not by too much or else it will be detected and the server can get defederated (or have its votes ignored).
Yes, after all other servers need this information in order to prevent double voting, you can’t just have servers sending each other information “somebody upvoted this” and also tell when servers are allowing users to vote more than once.
So upvotes and downvotes aren’t actually private, never have been, some servers may display them publicly even if most don’t.
The server hosting the post needs it.
It only needs to tell other servers the vote count, and the votes of people on that other server.
That may not be how it actually works, but that’s all that’s needed
Yes, but then you can have malicious servers sending fake numbers without other server operators being able to check whether this is at all plausible.
(It’s still possible for malicious servers to send fake votes, but server operators can see which users they are stated to originate from, then block that server if that looks like it’s doing that. At least that is my understanding.)
What do you mean “send fake votes”?
Or rather, who do you think should be responsible for identifying and blocking fraudulent votes?
And how do you reconcile votes that come from servers that you’ve defederated with? Should everyone have the same view of the post, or should people only see votes from servers that their server is federated with? What about votes from users you’ve personally blocked? Etc
I personally kinda think that the responsibility is on the server hosting the post, and that everyone should see the same (but anonymous) vote count, of which the hosting server is the single source of truth.
A malicious hosting server could use fake points to blast any message to the top of everyone’s feeds until manually banned or defederated
I’m not sure how giving every server access to the votes solves that.
The malicious server can make fake users to pump up votes. your server admin has to notice, then check the vote logs, then see what’s happening and defederate them. That’s pretty much what you described in your scenario, anyways.
It’s way easier to notice and defed when you can see these fake usernames
But it also has to be defended separately by the admin of every server that has a user subbed to that community. Seems like a large burden to put on small-mid instance admins.
I’d be surprised if my server admin was really paying attention that closely to votes on communities I’m subbed to, right?
I have to admit I don’t know the view that admins get of how their server intersects the fediverse.
Yes, that’s happened before. They were sending a very large number of votes, so it was immediately obvious. Even a couple dozen from an unknown instance will be noticed, when an admin sees it and says “huh I haven’t heard of that instance” and when they look there’s nothing there.
It’s only fake numbers for posts on the instance.
Not the first malicious instance, wont be the last.
There are plenty of ways to handle double voting without plaintext user strings. The fact that it’s done this way is just lazy and poor design and doesn’t actually do anything to prevent a rogue instance from vote spamming with fake users.
Hashing exists for this use case
Hashing alone if it’s just usernames isn’t enough. Need something like keyed hashes, but then malicious servers can lie about numbers of votes.
Otherwise you need something ridiculously overengineered like public but encrypted logs of user actions and Zero-knowledge proofs of correctness mapping everything to a distinct existing user without revealing who it is.
As I mentioned in another post: for consistency is better to have each server count total votes from their own users, send a signed & timestamped message with the count to the host of the post being voted on. Then the host can display a consistent vote count to everybody that shows where votes are coming from without manipulation of external votes.
Each individual server can lie about its count, but not by too much or else it will be detected and the server can get defederated (or have its votes ignored).
They already can do that by pretending to have users they don’t have. It’s definitely a quick way to get defederated.
And it wouldn’t be caught quickly or maybe even ever if they opted to use hashes instead of just showing who voted and when.
Over thinking.
Only the instance with the post needs the username to register the vote, the count can then be updated by the instance. Simple and lightweight
They should be.