172
submitted 1 year ago* (last edited 1 year ago) by zeste@kbin.social to c/kbinMeta@kbin.social

If you click on the "more" button under a comment or link there will be an activity tab. In this tab you can see everyone who has boosted, favourited or reduced the post. I'm not sure if this a
Is a good feature but it's interesting to see when someone decides to reduce all of your content for no reason.

you are viewing a single comment's thread
view the rest of the comments
[-] ernest@kbin.social 45 points 1 year ago
[-] Melpomene@kbin.social 29 points 1 year ago

Good discussion, there. I like the idea of allowing it to be set per instance; while it doesn't hide the votes from admins, changing the in-instance presentation of the data does allow an instance to customize the "feel" of the instance... much like Beehaw chooses not to use downvotes at all.

I'm on the fence re displaying them. I use the downvotes activity to search for bots / astroturfers and it DOES allow identification of bigots who downvote for that reason, but it also does provide a means of harassing someone for a downvote.

Really, a cultural shift from "Downvote = disagree" to "Downvote =Anti-factual, low effort, or bot" is needed.

Maybe making upvotes counter downvotes is a decent start? Right now, kbin is weighted toward downvotes; some users with thousands of upvotes and hundreds of downvotes are sitting in the negatives.

[-] I_Miss_Daniel@kbin.social 12 points 1 year ago* (last edited 1 year ago)

Kbin uses boosts as upvotes for their karma calculation, which is why you see the QI style scoring. Strange system.

[-] Melpomene@kbin.social 21 points 1 year ago

Yeah, that I get... it's just not intuitive for users. If downvote = -1 rep, then most people are going to assume that upvote = +1 rep, with boost being something like a "look at this post" option. But maybe that's just me?

[-] I_Miss_Daniel@kbin.social 8 points 1 year ago

I agree with you. It doesn't make sense to me. If it was me it would be =If(or(boost=1,upvote=1), karma=karma+1,karma=karma)

[-] ernest@kbin.social 59 points 1 year ago

Yeah, this is a consequence of recent changes. It has already been fixed on the test instances. The changes will soon be implemented on kbin.social

[-] Melpomene@kbin.social 8 points 1 year ago

You're the programming man!

[-] Melpomene@kbin.social 8 points 1 year ago

One thing I love about kbin? @ernest is super responsive. Looks like we'll see a fix soon enough!

[-] VerifiablyMrWonka@kbin.social 8 points 1 year ago

This is bug. It's fixed in dev. Shortly before the great migration started a change was made to bring kbin in line with lemmy but the bit that calculated the "karma" was missed and so it still uses boosts.

Not that I agree with the concept of karma.

[-] Melpomene@kbin.social 8 points 1 year ago

Though I was skeptical at first, I much prefer the "positive votes only" style that some Lemmy instances use. If you don't have anything nice to say, etc etc etc. Downvotes, at least, seem to suppress peoples' willingness to discuss controversial opinions.

[-] ShadowRunner@kbin.social 11 points 1 year ago

I understand, but it also makes it a lot more difficult to quickly make trolling and spam disappear.

[-] trynn@kbin.social 8 points 1 year ago

I think the Lemmy instances that disable downvotes are also the instances that have more heavy-handed policies and moderation. They're essentially centralizing moderation to the admins and mods rather than relying on community self-policing through downvotes.

[-] ShadowRunner@kbin.social 2 points 1 year ago

That's a very excellent point and shows the necessary trade-off to make that work.

[-] thingsiplay@kbin.social 1 points 1 year ago

@trynn One could argue with that. But Beehaw arguments that even without downvotes a self regulating community in form of upvotes is still in place. Because upvoted comments are on top. So the effect with or without downvotes is basically the same, from regulation point of view. But with downvotes it has an additional strong psychological effect.

But you are also right that such communities without a downvote mechanism do actually try to enforce through explicit moderation.

I know from my Reddit days that people try to mute people by downvoting an opinion they don't like. And once people have downvotes, many sheeps follow. And that in turn could lead to discussions that are popular only. That's why I am actually not hating this concept.

[-] rimu@kbin.social 5 points 1 year ago

Often, the option to downvote is the only thing stopping me from getting sucked into some stupid argument with an idiot. It is a massive productivity booster. Downvote and move on.

I wish kbin would hide posts with lots of downvotes...

[-] Entropywins@kbin.social 2 points 1 year ago

Meh I'll say what's on my mind if I feel the need... whether ya like it or not doesnt trouble me

[-] patchw3rk@kbin.social 8 points 1 year ago

I've had some time to think about it and I think I actually like the current setup. "Boost" provides more visibility to a post, while "upvote" and "downvote" is synonymous with agree/disagree.

In a way, I can disagree with someone AND boost it. Disagreeing with someone doesn't have to be hostile. I think it would be healthy if a community could disagree with each other in a civil manner.

I also like that if someone disagrees, that person cannot influence if the post gets less visibility.

[-] BaldProphet@kbin.social 3 points 1 year ago

Except downvoting does reduce content's visibility, and people are downvoting content that they don't really have anything to do with because it shows up in their All feed. Certain niche magazines and magazines for vulnerable communities are at risk of vote bullying in the current system.

[-] Adama@kbin.social 6 points 1 year ago* (last edited 1 year ago)

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 single_instance_system_account@kbin.social 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.

[-] VerifiablyMrWonka@kbin.social 3 points 1 year ago

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.

[-] Adama@kbin.social 2 points 1 year ago* (last edited 1 year ago)

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.

[-] VerifiablyMrWonka@kbin.social 2 points 1 year ago

Of course a bad actor can set up their own instance and just create thousands of fake bot accounts and do the same.

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.

[-] Adama@kbin.social 1 points 1 year ago

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

this post was submitted on 30 Jun 2023
172 points (100.0% liked)

/kbin meta

2 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 1 year ago