The best part of the fediverse is that anyone can run their own server. The downside of this is that anyone can easily create hordes of fake accounts, as I will now demonstrate.
Fighting fake accounts is hard and most implementations do not currently have an effective way of filtering out fake accounts. I’m sure that the developers will step in if this becomes a bigger problem. Until then, remember that votes are just a number.
deleted by creator
Client must computer all raw data. All individual moderation action (vote,block, subscribe) would be made public by default and stealth optional.
Only user led moderation has a future, it all has to be transparent, public, client sided, optional and consensual
It could be implemented on both the server and the client, with the client trusting the server most of the time and spot checking occasionally to keep the server honest.
The origins of upvotes and downvotes are already revealed on objects on Lemmy and most other fediverse platforms. However, this is not an absolute requirement; there are cryptographic solutions that allow verifying vote aggregation without identifying vote origins, but they are mathematically expensive.
deleted by creator
It’s nothing. You don’t recompute everything for each page refresh. Your sucks well the data, compute reputation total over time and discard old raw data when your local cache is full.
Historical daily data gets packaged, compressed, and cross signed by multiple high reputation entities.
When there are doubts about a user’s history, your client drills down those historical packages and reconstitute their history to recalculate their reputation
Whenever a client does that work, they publish the result and sign it with their private keys and that becomes a web of trust data point for the entire network.
Only clients and the network matter, servers are just untrustworthy temporary caches.
Any solution that only works because the platform is small and that doesn’t scale is a bad solution though.
That sounds a bit hyperbolic.
You can externalize the web of trust with a decentralized system, and then just link it to accounts at whatever service you’re using. You could use a browser extension, for example, that shows you whether you trust a commenter or poster.
That list wouldn’t get federated out, it could live in its own ecosystem, and update your local instance so it provides a separate list of votes for people in your web of trust. So only your admin (which could be you!) would know who you trust, and it would send two sets of vote totals to your client (or maybe three if you wanted to know how many votes it got from your instance alone).
So no, I don’t think it needs to be invasive at all.
deleted by creator
My point is you can have a mixed system. For example:
That’s not a ton of data, and the “special interest” users wouldn’t need to be synchronized to any other instance. The client would store the WoT data and update the server as needed (this way the server doesn’t need any transitive logic, the client handles it).
Facebook and Twitter have always had their equivalent of upvotes be public.
What if the web of trust is calculated with upvotes and downvotes? We already trust server admins to store those.
I think that could work well. At the very least, I want the feature where I can see how many times I’ve upvoted/down voted a given individual when they post.
That wouldn’t/shouldn’t give you transitive data imo, because voting for something doesn’t mean you trust them, just that the content is valuable (e.g. it could be a useful bot).