5
submitted 2 months ago* (last edited 2 months ago) by shazbot@kbin.social to c/kbinMeta@kbin.social

KES is the Kbin Enhancement Suite, a userscript/extension for (k/m)bin that provides a variety of customizable tools for users.

The last minor version included an initial attempt at a spam filter. This was chiefly done to address the low-hanging fruit of spam and scrub the most persistent pharma ads, etc. The approach was similar to that used by Ublock Origin or Steven Black's hosts file, in that it was a monolithic list of filter rules.

This was alright as a stopgap measure, but to the surprise of no one, the types of spam that continued to appear were innumerable in variety.

In an effort to have some filtering rather than none, the feature also went against the KES dictum about giving users choice to tweak their own settings: it was an all-or-nothing filter.

This update introduces v2 of spam filtering. The old logic has been retired, but may make a comeback at some point. A new sidebar page titled "Spam" has been added, and this will be a central place for anti-spam features.

The first of these efforts is a new filter that exposes the following options:

  • Hide posts from very new accounts

Users commented that there is no "gating" mechanism with registration, causing bogus accounts to be constantly recreated as a form of ban evasion. If you find that very new accounts have a high tendency to be spam, you can tick this setting to remove posts from very new users from the feed.

This does not block the user outright, merely hiding the post. This effectively gives some "break-in" time for the user to prove themselves. After a certain threshold, the user will fall outside of the "new account" window; if they continue to engage in spam-like behavior at that time, they should be caught by the other ban filters below.

  • Hide posts with abnormally low relative rank

Users with aggregate posting activity that does not necessarily resemble spam at first glance, but which periodically post spam/off-topic/controversial threads in the wrong communities, have a high likelihood of being astroturfers. This option hides such posts from the feed if the relative vote weight is egregiously outside the norm. Like the above, it does not block them outright.

  • Block users with spam-like activity

This feature blocks users outright if they engage in spam, mass posting, and other robotic behavior. It is less permissive than v1 of the spam filters, which failed to catch a lot of spam that was not explicitly blacklisted in the filter list. This new approach is more generic and does need constant updating of the spam filters.


By default, all three options are enabled. I find this combination gives the best results so far. Note that infinite scrolling should be enabled for best results, and it may take a little while when navigating to a magazine for the results to be filtered.

Give it a try and see if this negates the spam issue or improves your experience. What other filter options would you like to see added?

The remainder of the changelog follows:

Add-ons


Filter advertisements (@shazbot)

Location: Spam > Filter advertisements

Updated filtering logic to v2, as described in the preamble of this post.

Collapse pinned posts (@shazbot)

Location: Threads > Collapse pinned posts

This simple feature groups together pinned posts on the magazine index and collapses them by default. Click the toggle area at the top of the magazine index to expand pinned posts. This is especially useful on magazines with many pinned posts that are not regularly archived, such as /m/kbinmeta.

API


Added the helper function isThread() to the API. This returns true if the current window location is a thread inside of a magazine. This can be used to abort if the feature is intended to only apply on the thread index. In the future, a more expanded function will be provided that returns the type of page from a list of enums.

[-] shazbot@kbin.social 5 points 3 months ago

Using this approach, I am seeing none of those posts on /science. I updated the filters a bit today. The top post is a legitimate article from 2024-04-13 and is by HeartyBeast.

Now, I understand that this is seen as an unnecessary step (too fancy) for some. People want zero ads out of the box without anything extra. So I'm thinking about the next approach here.

Framing the problem:

  • Filtering should be automatic
  • End-user wants zero additional setup
  • There is no active upstream development
  • It's not possible to inherit moderation of a magazine due to some queue of moderator application requests that is not being approved

The third point and fourth points are important here, since that's currently intractable. You can't reconcile zero additional setup with that.

But let's suppose becoming moderator of a defunct magazine (point 4) were possible while point 3 remained unresolved. In other words, at least moderators can try to pick up the pieces. Something being underestimated here is how annoying it would be for the moderator to manually cull posts every single day. I think you would have instant turnover after a couple of weeks once the tedium sets in. Manual solution is not good. Clearly, automation is needed on the moderation side.

So assuming you could actually inherit a magazine, but with no guarantee of upstream development, what about restructuring the tool above so that it's for moderators, instead of end-users? That's pretty easy, and I could make it something the moderator clicks once and it's done, auto-banning the posts. This is a pretty good method.

But you can't inherit moderation right now, so that's back to square one.

Realistically, that leaves these options at the moment:

  • Wait (a long time) and see
  • Use the tool above and make magazines readable, albeit at some sacrifice of convenience (?)
  • Migrate to another instance

Third approach is the path of least resistance and is best for most casual users. Second is for diehards who cannot move instances due to some personal or technical reason. First approach is the most annoying and eventually leads to the third approach after frustration sets in.

Pick your poison, I guess. I can't think of any other prophylactic approach at the moment, maybe this comment triggers some idea.

9
submitted 3 months ago* (last edited 3 months ago) by shazbot@kbin.social to c/kbinMeta@kbin.social

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.
12
submitted 4 months ago by shazbot@kbin.social to c/kbinMeta@kbin.social

KES is the Kbin Enhancement Suite.

This is just an update to note that the tool has undergone a total quality audit to ensure that all of its add-ons support both kbin and mbin instances and behave in an expected fashion regardless of which instance type you are using.

If you had previously tried KES on an mbin-type instance and encountered anomalous behavior, you should now find that it has full compatibility.

The full release notes can be found here

19
submitted 5 months ago by shazbot@kbin.social to c/kbinMeta@kbin.social

"EXIT" -- Export Across Instances Tool

This is a simple and self-contained tool that helps automate the process of exporting your magazine subscriptions from one instance to another, provided you have accounts on both.

Could also be used to copy subscriptions from one named account to another named account on the same instance, or to back them up for later.

Instructions and tool available here

Code runs locally in your browser only.

[-] shazbot@kbin.social 3 points 7 months ago* (last edited 7 months ago)

@Pamasich @speck

I have completed an audit of the mod and observed the following issues:

  1. Does not properly unset classes and restore the page to an intact state when turned off: this was having the side effect of making the threaded lines look incorrect when toggling on/off in place. The mod should not leave dangling containers around after it is toggled off. The mod creates an outer container so that the "expando" lines flow all the way down through the child elements, but when turned off, these child elements need to be moved back out of the container to be adjacent to each other and the container removed. => Fixed locally.

  2. Does not properly unset event listeners attached to nested comments. Same as above, tends to leave dangling listeners and does not unset itself cleanly. => In progress.

  3. Because it physically manipulates the DOM and moves sub-comments into their own container down the tree, triggers an event (likely a bug) on Kbin's side whereby any time the DOM is updated for that element, Kbin appends a more element (text expansion button) if the text overflows a certain length, even if a more element is already present. You can test this by creating a dummy div above or below a long comment and then moving the long comment before or after that div. Simply moving its position in the DOM will trigger the creation of another more element inside. And because the mod puts each comment into its own container for the purposes of threading nested chains of comments, this will trigger the creation of as many mores as there are indendation levels. So for a comment chain 5 replies deep, there will be 5 mores. This is further exacerbated when toggling the mod on and off, since these mores are not getting wiped and will just keep getting stacked up. Since this is also an upstream issue, our only alternative here is to walk through the tree and remove the extraneous more elements after nesting occurs. This is similar to your CSS solution, but instead of masking them, physically deletes them, otherwise we will have a constantly growing tree of mores every time nesting happens. I guess this should also be reported upstream as well. Kbin seems to expect no DOM manipulation to occur, which is reasonable, I suppose, but might be better if the callback doesn't insert the more element at all if it's already present. => Easy fix on the Kbin side, in progress.

[-] shazbot@kbin.social 3 points 9 months ago

Hi, this feature is still available and working in KES under Threads > Permanently Hide Posts. The hide link appears next to the more button, not inside of the more menu. Give it a try.

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

Most of these are supported in my theme (if you don't mind the austere appearance), and can be used in conjunction with my scripts to add what you asked for.

As for no. 2: not sure what you are referring to by "all," here. What content specifically? You mean show everything before the page fold?

As for no. 3: what page is that? Aren't magazines appended with an @ if they are on other instances?

Also check https://kbin.social/m/kbinStyles for a wealth of other client-side scripts to hot-rod your experience

2

Adds a direct 'Mail' link next to usernames if they are registered on the kbin instance

Image

Requires *monkey extension (greasemonkey, tampermonkey, violentmonkey et al)

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

This userscript replaces the superlong scrolling marquee of links on profile pages with a selection dropdown so that you can easily navigate to submitted posts, comments, followers, etc. Works on any profile page including your own.

Before
After

Requires monkey extension to run (greasemonkey, tampermonkey, violentmonkey, et al)

Edit: previous bugs should be fixed on all versions now

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

Alright, I've updated it to 0.0.5 and now it handles both inline and fixed-size index thumbnails. The thumbnails on the index get cropped to fit the hard dimensions of the squares and maintain the correct aspect ratio. In the case of inline images, they just get scaled to 50% of the original size with no constraint on the height.

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

Alright, those index thumbnails are confined to a 220x145 square, so we can handle those separately by using the cover method of the object-fit property to scale them. Give me a minute to update it...

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

I was kind of leery of making this global because I didn't want it to affect thumbnails on the thread index, since they must be confined to a finite area, whereas in a thread they can flex downward. (The fetched image can be an arbitary size.) But it looks like they don't use the same selector, so should be safe.

Edit: I've updated it to support thread index, inline images, and profile pages and the differing aspect ratios

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

This userscript unsquashes inline images in comments by fetching the source image and downscaling it to 50%.

Requires *monkey extension to run (greasemonkey, tampermonkey, violentmonkey, et al)

Edit: also updated it to support the thread index

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

Sorry if that was unclear. If you look at the dependencies at the top of the instructions, you need the Stylus extension. I believe it's only available in Firefox and Chrome. Once you have the extension installed, navigating to scripts like that one will bring up an install menu that lets you load the script and choose the parameters you want. It looks like this

I'll update the README tomorrow to make this clearer.

[-] shazbot@kbin.social 20 points 1 year ago

I've taken a stab at a client-side theme here that should be easy for people with zero technical literacy to install. The main goal was to parameterize the options and create a more forumlike layout. This is merely a stopgap measure, but has greatly improved the readability for me.

39

Hello, this is a client-side theme focused on high readability and removing extraneous visual widgets and icons. It is based on the way I liked to read content on that "other site."

Image

For better or worse, the current kbin layout is very "mobile" in design and not the best for reading longform text on a desktop. This theme focuses on easing the layout and hopefully making threads look more forumlike.

It does take a "scorched earth" approach in removing stuff I don't like, but everything that starts disabled can be enabled again via the radio buttons provided, allowing you to toggle on/off various widgets on the fly.

This includes:

  • sidebar
  • footer
  • activity
  • thumbnails
  • previews
  • short description
  • avatars
  • upvotes, downvotes, or both
  • icons
  • elements of the text submission form
  • numerous other elements

In addition, you can change the base color scheme via the color picker in order to globally control things like:

  • body color
  • link colors
  • upvote/downvote colors
  • blockquotes, code blocks, input fields
  • hover/focus color
  • text color
  • etc.

Disclaimer: I have tested this at 1440P on a desktop environment at various scaling levels and dimensions and it seems to mostly be OK. I have not extensively checked for glitches on mobile aside from some rudimentary mocking. If you find something wrong, feel free to make a PR or inbox me.

Frontend is not my main focus area, so there may be some anti-patterns or things that are objectively stupid, particularly around the way I manipulated elements on the grid. Again, if something is being implemented wrongly here, please advise.

view more: next ›

shazbot

joined 1 year ago