You made me curious, so I checked the source code for both comments and posts. This information isn’t available to anybody without direct database access, but your admins in theory could check in the database what you’ve voted on.
Presumably this is necessary for debug reasons and to avoid double-voting, or even worse spam-voting. Reddit has this info in their databases too, I’m pretty sure, for similar reasons.
I’m pretty confident that only vote totals are federated, not who voted for what, so this is restricted to your own instance admin
I haven’t seen a database yet (Thinking of spinning up my own…) but I’d imagine it’s actually that your vote history is saved on the instance of the thing you voted on. So if you are from shitjustworks and upvote a post in a community in LemmyWorld, I’d imagine LemmyWorld’s database says upvote from user xyz@shitjustworks on post/comment abc.
This is my educated guess on how it works. I could be wrong, but keeping a users upvotes saved on the users local instance would be pretty impractical. I think it’s more aptly that an admin can see who upvoted things on their instance but can’t see everything their user’s have upvoted and everything that visitors have upvoted in their lifetime. Just their interaction with their particular communities. I imagine (Again, if I’m right) that’s why there’s no total karma for a user because keeping track of that would be a pain in the ass.
The way federation works is that when you subscribe, that community gets “pulled in” to your local instance. So when you go to https://myinstance.com/c/[email protected], what’s actually happening is that you’re interacting with a local cached copy of that community. Your instance then federates your interactions back out regularly, along with any other users from your instance that have interacted.
So, TL;DR: it actually makes perfect sense that the user - vote connection remains local
Yeah it’s cached but it has to offload that at some point right? It’d be crazy for a server to keep a 1:1 copy of every instance and action ever on the fediverse? I’m sure yeah it pools all that info to send back to the other servers but both servers keeping a perfect copy of the information doesn’t sound right. I imagine the cache is limited copy of everything and once stuff is sync’d the offload aspects unrelated to their own instance.
Reading the docs now, they don’t make it super clear what’s cached entirely outside 20 posts when a community is first discovered.
This would also mean any instance that defederates would loose all post/comment/vote history from anyone that wasn’t in their local instance. Beehaw currently still has all that from the 2 instances they just defederated from despite no longer being in the pool.
The cache still lives on even after blocking, outside of direct admin intervention. Beehaw.org still has everything from users on sh.itjust.works and lemmy.world up till the block, and now the cache is stale.
EDIT: Just tried going to lemmy.directory. Unsurprisingly, their server crashed xD
This seems like a potential severe issue though - with just a few accounts, you could, without arousing too much suspicion, just try to get as much communities mirrored to your server as possible. This also means that, with a sufficient amount of users, every (large) fediverse server will have basically a complete copy of all other servers. It seems to me that this will lead to severe scaling issues, as the cost of hosting an instance will just go through the roof once a certain user count is reached.
The overhead of community mirroring is much lighter than you might imagine. Most of it is just text. An entire community is usually as light as a few kilobytes, especially when you consider that images are not copied over, they are image links pointing to the original instance.
You made me curious, so I checked the source code for both comments and posts. This information isn’t available to anybody without direct database access, but your admins in theory could check in the database what you’ve voted on.
Presumably this is necessary for debug reasons and to avoid double-voting, or even worse spam-voting. Reddit has this info in their databases too, I’m pretty sure, for similar reasons.
I’m pretty confident that only vote totals are federated, not who voted for what, so this is restricted to your own instance admin
I haven’t seen a database yet (Thinking of spinning up my own…) but I’d imagine it’s actually that your vote history is saved on the instance of the thing you voted on. So if you are from shitjustworks and upvote a post in a community in LemmyWorld, I’d imagine LemmyWorld’s database says upvote from user xyz@shitjustworks on post/comment abc.
This is my educated guess on how it works. I could be wrong, but keeping a users upvotes saved on the users local instance would be pretty impractical. I think it’s more aptly that an admin can see who upvoted things on their instance but can’t see everything their user’s have upvoted and everything that visitors have upvoted in their lifetime. Just their interaction with their particular communities. I imagine (Again, if I’m right) that’s why there’s no total karma for a user because keeping track of that would be a pain in the ass.
The way federation works is that when you subscribe, that community gets “pulled in” to your local instance. So when you go to https://myinstance.com/c/[email protected], what’s actually happening is that you’re interacting with a local cached copy of that community. Your instance then federates your interactions back out regularly, along with any other users from your instance that have interacted.
So, TL;DR: it actually makes perfect sense that the user - vote connection remains local
Yeah it’s cached but it has to offload that at some point right? It’d be crazy for a server to keep a 1:1 copy of every instance and action ever on the fediverse? I’m sure yeah it pools all that info to send back to the other servers but both servers keeping a perfect copy of the information doesn’t sound right. I imagine the cache is limited copy of everything and once stuff is sync’d the offload aspects unrelated to their own instance.
Reading the docs now, they don’t make it super clear what’s cached entirely outside 20 posts when a community is first discovered.
This would also mean any instance that defederates would loose all post/comment/vote history from anyone that wasn’t in their local instance. Beehaw currently still has all that from the 2 instances they just defederated from despite no longer being in the pool.
This is why outside of complete madlads intentionally subscribing to everything, instances only pull in communities that at least one user on the instance have subscribed to
The cache still lives on even after blocking, outside of direct admin intervention. Beehaw.org still has everything from users on sh.itjust.works and lemmy.world up till the block, and now the cache is stale.
EDIT: Just tried going to lemmy.directory. Unsurprisingly, their server crashed xD
This seems like a potential severe issue though - with just a few accounts, you could, without arousing too much suspicion, just try to get as much communities mirrored to your server as possible. This also means that, with a sufficient amount of users, every (large) fediverse server will have basically a complete copy of all other servers. It seems to me that this will lead to severe scaling issues, as the cost of hosting an instance will just go through the roof once a certain user count is reached.
The overhead of community mirroring is much lighter than you might imagine. Most of it is just text. An entire community is usually as light as a few kilobytes, especially when you consider that images are not copied over, they are image links pointing to the original instance.
Fair point - thanks for the info!