this post was submitted on 17 Feb 2025
366 points (96.2% liked)

Fediverse

30290 readers
688 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

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 2 years ago
MODERATORS
 

Upvotes seem to just federate as likes and dislikes.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 71 points 5 days ago (5 children)

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.

[–] [email protected] 23 points 5 days ago* (last edited 5 days ago) (1 children)

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

[–] [email protected] 23 points 4 days ago (2 children)

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

[–] [email protected] 3 points 4 days ago (1 children)

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.

[–] skulblaka 7 points 4 days ago (3 children)

A malicious hosting server could use fake points to blast any message to the top of everyone's feeds until manually banned or defederated

[–] [email protected] 4 points 4 days ago (1 children)

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.

[–] [email protected] 4 points 4 days ago (1 children)

It's way easier to notice and defed when you can see these fake usernames

[–] [email protected] 1 points 4 days ago

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.

[–] [email protected] 2 points 4 days ago

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.

[–] [email protected] 1 points 4 days ago* (last edited 4 days ago)

If that's the concern it's better to have each server send a signed counter of votes coming from its own users to the hosting server for the post being voted on, then people can see which servers three there's how many votes from.

This provides the same privacy as intended before (your account host knows your votes, nobody else does) and you can see which servers are acting suspiciously while allowing everybody to get a consistent view of votes (the host simply tally up the votes from each other server, and offer up the signed counts on request)

[–] [email protected] 2 points 4 days ago

It's only fake numbers for posts on the instance.

Not the first malicious instance, wont be the last.

[–] [email protected] 7 points 4 days ago (1 children)

Hashing exists for this use case

[–] [email protected] 2 points 4 days ago* (last edited 4 days ago) (1 children)

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

[–] [email protected] 2 points 4 days ago (1 children)

but then malicious servers can lie about numbers of votes.

They already can do that by pretending to have users they don't have. It's definitely a quick way to get defederated.

[–] [email protected] 2 points 4 days ago

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.

[–] [email protected] 6 points 4 days ago* (last edited 4 days ago)

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.

[–] [email protected] 9 points 4 days ago* (last edited 4 days ago)

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

[–] [email protected] -1 points 4 days ago

They should be.