/kbin meta @kbin.social shazbot @kbin.social 1 mo. ago

KES 4.1.0: Improving the signal to noise ratio by blocking unsolicited ads

The blurb below is excerpted verbatim from the release notes. For the full release notes, see here.

Repository: KES

Many of you are aware of the "canned meat" problem on kbin.social, with some magazines being inundanted with garbage posts.

The latest version of KES ships with an experimental new feature you can enable that attemps to filter these posts and block the users who posted them based on certain heuristics.

This feature is experimental, but I see a lot of users voicing frustration at the problem, so now seems like a good time to start collecting feedback. You can start using this feature immediately and it should not have any adverse effects, but its coverage is still being expanded.

You can find it under General > Filter advertisements. For best results, it should be used in conjunction with infinite scrolling enabled in the kbin sidebar, so that new content is loaded in as posts are removed.

As you navigate through a magazine, KES will remove offending posts from the index and then permanently block the user of the post. This feature is also preventive, as variations of posts made under different usernames will continue to be flagged. The goal is to avoid the tedious process of "whack-a-mole" and cull these posts without manual intervention.

Initially, KES will be removing posts from the index, but as it builds your blocklist up for you, such posts will stop appearing in the thread index altogether, and you should see the overall signal to noise ratio improving. Outside of your blocklist, subsequent posts that meet certain criteria will continue to be culled regardless or when or where they appear.

I am currently using /m/science and /m/opensource as a control. If you navigate to those magazines and compare the results before and after enabling this feature, the difference should be clear. After enabling the feature and scrolling all the way back to 2023, there should be few if any unsolicited ads on the page.

Hopefully this improves readability and encourages participation in communities that otherwise seemed impenetrable at first glance. In fact, once you scrub the garbage posts, you'll be surprised to find that there are legitimate posts being made fairly frequently in these seemingly "dead" communities--the posts were just buried in the heap.

However, canned meat comes in a lot of different flavors, and each magazine has slightly different permutations. The coverage in this initial version is not exhaustive, but it attempts to be thorough. This should greatly cut down on the most annoying ads. If there are specific (most likely unmoderated) magazines you are still having a problem with, please leave a comment listing the magazine. You don't need to point to specific posts or users; the magazine name is enough here for me to analyze what kinds of posts are appearing.

Some additional notes:

For the time being, this feature does not report the post to the magazine's moderator (usually nonexistent). By kbin's design, a post can only be reported at most by a single user, so this seemed like a reduplication of efforts to me. But auto-report can be added if necessary.
This feature works on any instance, but is chiefly designed for kbin.social and is probably unnecessary elsewhere.
I have not taken a look at microblogs yet, so I don't know if this problem is happening there, too (please let me know). For now, this works on the thread index of magazines.
For best results (if you want to quickly bootstrap your blocklist), I suggest enabling the feature and scrolling through an affected magazine for awhile with infinite scroll on to build up the blocklist as new posts load in, then refreshing the page if necessary.
The "random threads" sidebar is fundamentally flawed because it shows content even if you've already blocked it. So I recommend enabling General > Hide sidebar elements > Random threads in conjunction with this feature.

9 comments

Thanks for the hard work!
Even though I don't post much so mostly ignore all those messages, still it is a big problem. Until we get it sorted out having tools like these helps stop "bleeding" by people who want to use kbin.
Had few pop up on my magazine ~~even though there is barely a traction~~ but saw few times bloat when posted on other magazines which is really discouraging.
- I don't read magazines in-depth much either, so I wasn't aware of the extent of the issue at first, but I was appalled at what I saw. I agree with you that it creates a negative impression for anyone wanting to venture into or use a magazine. I know that needing KES upfront may be a non-starter for some people, but for me the difference with filtering is night and day now.
So far don't see the option but ready to jump on it.
- How do you typically update your KES?
  
  actually I don't. I read this on kbinmeta and thought it was a general improvement to kbin. oh well.
Preventing this issue doesn't seem like a userscript issue (though that's definitely a good start).I think the auto report function is severely needed; it's happening everywhere. If the script can automatically block any user whose post it suppresses, it would be awesome.

But I think the issue is that we need to get support top-down on this.
- If the script can automatically block any user whose post it suppresses, it would be awesome.
  
  It does! I've reworded the OP to hopefully make that clearer. After using this approach for a few days, my blocklist (generated entirely programmatically) is ten pages long, and there is nary a bad post in sight. I'm expanding the filters on a daily basis.
  
  I think the auto report function is severely needed; it's happening everywhere.
  
  The idea is that it takes the burden off of myriad (N) users having to manually do this themselves, and lets a single user (the KES custodian) prepare the filters, which then propagate out to any user of KES. Instead of 1,000 people manually blocking, one person builds the heuristics, and everyone benefits.
  
  Preventing this issue doesn't seem like a userscript issue...but I think the issue is that we need to get support top-down on this.
  
  I understand, but the stated goal of KES is addressing issues that can't, or won't (due to some design conflict), be addressed, or which fall through the cracks. At the moment I'm seeing a lot of people voicing frustration, but due to the skeleton crew situation with administration of the site, it seems like screaming into the void. Not that there's anything wrong with that, and hopefully it gets some traction. But my job with KES is just to provide fixes for the end-user, albeit of a third-party nature.

You've viewed 9 comments.