this post was submitted on 30 Jun 2023
183 points (100.0% liked)
/kbin meta
639 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 2 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I see that ActivityPub makes it hard to do it and if it can’t be done then it should be visible (so people can know and act accordingly)
The only “alternative” approach I can see would be to have a per instance account that is given the activity (say upvote/downvote)
So… let’s say I’m on kbin.social and upvote this comment.
Kbin.social knowing me (since it’s my account) logs the upvote but does so as if [email protected] did the upvote.
That is then what is replicated across the fediverse.
I assume that breaks the “intent” of the protocol and could be an issue but does let other instances decide to filter out that activity (if they decide to do so) by having some attribute or flag that denotes that this “account” is the fediverse instance account (e.g. not a user).
Boosts, however, should be shared since it’s like a retweet/shout out and are meant to be shared.
Of course that means I can no longer see my own upvote/downvote activity.
If that was also wanted then you could add a table that basically logs that but isn’t federated. E.g. a local instance reference that can be used for that instance to show the activity.
This way there’s less chance of an issue of somebody knowing a users account seeing activity like this:
A man, say in Iran, upvoted something about the prophet that somebody else found disrespectful
A christian teen upvoted something about atheism.
A woman reading about how to leave a domestic abuse situation.
Somebody curious about transgender reassignment
Either there needs to be a way to minimize the risks of such activity being seen/shared across the fediverse or it needs to be very very clear that even if you don’t see it that what you do is shouted across the fediverse and that others can and will be able to see it.
So what happens with 300 people downvote a post and 500 upvote it? For that to work you'd need an 'account' per post/vote/user combination. Now your instance has 1000's of bot accounts that are now indistinguishable from bad vote manipulation.
Yeah. Because each instance would have a record of that but there’s nothing to stop a bad actor from doing that on one instance and federating that out.
Of course a bad actor can set up their own instance and just create thousands of fake bot accounts and do the same.
Edit: The more I think about it @VerifiablyMrWonka the only way to do it would be to have some kind of activitypub transaction that is flagged as an instances reputation.
E.g. it’s the same as using the per instance account but it allows you to say “here’s how kbin.social” calculated the reputation/weight of this item.
And then each instance can opt to include that or not as they see fit. Maybe they federate with all instances but only show the weight/reputation “favorites”/“reduce” from those that they trust to maintain that info. Lemmy.world, sure, but the new instances such as haxor.1488.de.feder.at yeah… that’s probably a no so by default all of those don’t show/include in that instances feed.
A competent admin would then just defederate from them. Easy. But now throw in that all kbin instances look like bot fests and what do you do? Maybe what lemmy.ml have done and just block kbin useragents at the firewall.
Having an aggregate account that just sends totals could work, but then vote brigading just became even easier. What's that aggregate bot? Did you just send a vote ratio of 300:1.9k for this comment? Lovely.
It's a very hard problem to solve and I'm not sure it's doable. The only thing keeping ActivityPub together is the fact that it's so transparent and bad actors are easily spotted and blocked. As soon as you muddy the waters the primary benefactor is the bad person.
That’s true. Just something to consider since there are real life bad actors and things can and will be a security/safety risk for some groups