Kbin dev said it won't fix this as it wouldn't be easy (one user proposed to hide votes for Kbin when posts and comments come from Lemmy):
https://codeberg.org/Kbin/kbin-core/issues/3
The problem here is how Kbin handles the information obtained from Lemmy, I guess one way to solve this could be to block interoperability between Lemmy and Kbin.
Anyone can stand up their own instance, subscribe to remote communities, and start receiving all the data necessary to show those communities. That includes posts, comments, and votes too.
Every instance operator is in control of a database containing all the activity for communities that instance's users are subscribed to. They can do whatever they like with that data. That's a consequence of how federation works.
The protocol as it stands today is also generally vulnerable to any malicious instance. A malicious Lemmy server could emit spam, send out bogus votes, or alter its users' comments after the fact (ahem, spez) and disseminate the modified versions. The main tool that other instances have to deal with a malicious instance is ... yup, defederating.
Ultimately, other federated services in Internet history have adopted different ways to deal with this problem:
IRC doesn't have a single federation; it has many federations ("IRC networks"), and server operators form peering relationships with one another based on mutual trust and agreement to uphold various rules. A given chat channel only exists on a single IRC network; you can't reach Libera.chat's #linux from a DALnet server. And occasionally a federation completely blows up — see e.g. the 2021 collapse of the Freenode network due to admin abuse.
Usenet pretty much floundered on spam mitigation because well-behaved servers didn't eject the malicious and ill-maintained ones.
Email has dozens or hundreds of different ways of dealing with bad instances (i.e. mail servers that emit spam), including published blocklists of known offenders' IP addresses. But even then, major mail servers depend on all manner of filters (including ML classifiers these days!) on top of straight IP blocking.
the information must be public for activitypub to work properly. not exposing it through the UI just means people are less likely to be aware that the information is not private
I think it is fine, since likes on twitter have been public. People just need to change their habits on upvoting and downvoting that they got used to when they were on reddit. So need to adjust to how people would go and downvote whatever comment they disliked and move on. Now that stuff is public, so maybe it can help against brigading?
I'm more concerned about the more toxic people having access to the names and profiles of people who downvote them. Reddit had a lot of crazies, and it seems like a good tool for targeted harassment. Not to mention, what's stopping them from having alt accounts on different instances and continuing even after they've been blocked or even banned on one account?
A boost is like a Twitter "retweet", it reposts the content to the booster's personal timeline for people who follow them to see. For example, right now, two people have boosted your question. If you go to "more --> activity" you can see who boosted you, go to their profiles and find your comment "What's the difference between a favorite and a boost?" on their respective profiles under boosts.
That's true, it is visible. But this information is public, and anyone who has their own instance also has access to it. The interface is consistent with Mastodon and other platforms where you can view likes and boosts. There are several ways to improve this - completely hide this information in the threads section, hide the activity of users from remote instances, or exclude Lemmy's instances from the activity... but still... It's just covering up one's eyes.