3 or 4 spam "Buy Phloboxidril Now In Your Area" posts per day were tolerable. 20 to 50 aren't. I know I could block the magazine, but I'm just one of the many who are subjected to it....
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.
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.
I understand if you don't want to add yet another third-party tool just to browse the site, but if you feel at all inclined, give it a try. For me 99% of magazines went from unusable to essentially clean.
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.
I'll try to reproduce this and look into tightening the error handling. A 404 error should imply that the magazine is not available at the remote. Are those magazines available at the target instance? Agree that those should at least be added to the log--perhaps should add a third category for "Unavailable." Remember that it will also navigate you to the magazines list at the end for visual confirmation.
When you said community subscription, were you referring to something in particular, or just using this term generically to refer to magazines?
Hmm, this is a good finding. Just on a cursory review, I had a look at the magazines list on fedia, and it does list magazines with zero threads, comments, posts, or subscribers on them (on other instances other than kbin.social). So maybe you've discovered a problem with kbin.social's federation? I don't know too much about this issue, so this is just my initial reaction before looking into it further.
I have made some modifications that should prompt you to click a button to copy the contents to the clipboard, rather than doing it automatically. This is done because Safari only permits modifying the clipboard if there was direct user interaction. Can you try again?
Addressing your issue, I have bumped the version number to 0.1.3 and made a change to the async method handling so that instances not available at the remote get added to the fail log correctly.
This doesn't explicitly address the fact that some instances are unfederated, but it will make the log results clean.
As for the federation issue, what I've initially found is that a user on an instance has to visit the remote instance for the home instance to be aware of this remote instance, and a user (could be a different user) has to subscribe to that instance for the posts to start federating. What is unclear is how a user on an instance visits a remote instance from the home instance, as this is implementation-specific and could vary from instanc to instance.
I'm moving over to Mbin (hopefully ernest can sort kbin out, but until then), and id like to bring my subscriptions over without manually doing it. any methods? thanks
I wasn't able to reproduce the issue on a default kbin setup with KES either on off. The "always expand post bodies" feature of KES only applies to bodies, but I could extend it to support comments as well so that they auto-expand. What I didn't observe was any situations where the expansion bar obscures the text. Do you have a screenshot of that?
Thanks for looking into this. I've been meaning to audit this mod, but was a bit busy this week. In light of this report, this seems like as good a time as any.
Unfortunately, the mod is no longer maintained by the original author, so I'll have to inherit it and refactor it. I feel it is overengineered for what it attempts to do, so it should be streamlined and the aforementioned issues fixed. I am also aware of the issue that the mod fails to unset itself properly when turned off. I am really not satisfied with its current functionality.
Root cause analysis and solutions are described in a subsequent comment
I have completed an audit of the mod and observed the following issues:
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.
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.
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.
I have resolved the aforementioned issues with a hotfix on the testing branch; please test when time permits. Executive summary:
The mod fully restores the DOM tree to its original state when toggled off. It is now possible to toggle the mod on and off on the same page without reloading, and changes will behave as expected.
For reasons of security, the mod no longer allows clicking the post headers or post body as a means of collapsing/expanding comments. This was attaching unnecessary listeners to elements on the page, with no way of clearing them when toggled off (besides hard refreshing). Now the only approved way of expanding/collapsing is to use the +/- icon or colored bars.
The mod erroneously modified the CSS of profile pictures to give them rounded borders, which was unspecified by its intended behavior and documented nowhere in the description. Now they conform to the standard square format.
The superfluous mores are being removed now for comments with overflow text. What I thought would be a quick fix turned into hours, and I thought I was losing my marbles over this one for a long time, since the tree clearly showed numerous duplicate mores, but only one per comment was being shown at runtime of the script. At first, I did not seriously think that the mod was completing its runtime cycle prior to the duplicate mores being spawned, but indeed this is what was happening. For now, I have added a 20ms sleep before clearing the extra mores, and this seems to suffice to let them propagate before the mod can continue with the cleanup phase. This seems satisfactory for now, short of attaching observers to wait for the duplicate mores to appear.
I believe that covers everything. It should be possible to switch the mod on and off at will now and see no adverse effect.
I know there's block, but "block" currently blacklists the entire magazine. If I click on it, it wipes all the threads on /all/, prevents me from looking at threads on the magazine landing page and all comments in the threads should I venture in. A "filter" would be a soft block that just clears it from my feed on the main page....
Hello, I have added this feature to KES (third party extension) today. I believe it is working correctly based on your requirements:
Show an icon next to magazine names on the main thread index (https://kbin.social or https://kbin.social/sub if logged in). Click this icon to "softblock" threads from that magazine from appearing on your main thread index. This does not block the magazine outright: you can still go to the magazine directly, so it is less aggressive than a total block.
Show a Softblock/Unsoftblock button in the sidebar of magazines, as well as in the Magazines index located at https://kbin.social/magazines. As you would expect, this button has the effect of adding/removing a magazine from your filters.
Show a tab at the top of the Magazines index that you can use to centrally manage your softblocked magazines. For the time being, this is merely informational.
Full details can be found in the release notes here over at /m/enhancement.
Let me know if this gives you the functionality you wanted.
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.
As scrolling to the bottom of the page to leave a comment can be a hassle on posts with lots of existing comments, an option to put the thread comment box above existing comments would be helpful....
If you install KES and navigate to the setting Threads > Rearrange post order, you can dynamically change the position of the OP, the comments, the add comment box, and other elements and choose which place you want them to be in descending order. You can direct other questions to our magazine on /m/enhancement as well.
Please turn off science (kbin.social)
3 or 4 spam "Buy Phloboxidril Now In Your Area" posts per day were tolerable. 20 to 50 aren't. I know I could block the magazine, but I'm just one of the many who are subjected to it....
KES 4.1.0: Improving the signal to noise ratio by blocking unsolicited ads (kbin.social)
The blurb below is excerpted verbatim from the release notes. For the full release notes, see here....
Banning spam accounts (kbin.social)
Banning spam accounts on kbin.social is a cumbersome affair....
KES 4.0.0 now adds full mbin compatibility (kbin.social)
KES is the Kbin Enhancement Suite....
KES 4.0.0 now adds full mbin compatibility (kbin.social)
KES is the Kbin Enhancement Suite....
EXIT 0.1.0: Export subscriptions across kbin/mbin instances (kbin.social)
"EXIT" -- Export Across Instances Tool...
Any way to export and import subscriptions? (kbin.run)
I'm moving over to Mbin (hopefully ernest can sort kbin out, but until then), and id like to bring my subscriptions over without manually doing it. any methods? thanks
Is there a way to message a user? (kbin.social)
I have not seen an option so replying to a thread seems to be the only way that I can tell.
[Solved] How to get rid of the arrows at the bottom of comments which collapse/expand the text? (kbin.social)
They always obscure part of the text, no matter what. I juat want the full text....
Two requests for microblog incorporation into the main feed. (kbin.social)
First off, I absolutely love that microblogs are a part of my main feed now....
Could there be a "Filter" button for magazines? (kbin.social)
I know there's block, but "block" currently blacklists the entire magazine. If I click on it, it wipes all the threads on /all/, prevents me from looking at threads on the magazine landing page and all comments in the threads should I venture in. A "filter" would be a soft block that just clears it from my feed on the main page....
Could we have 'hide' post back again please? (kbin.social)
There used to be a handy 'hide' option hiding under the 'more' menu. It seems to have been removed. Any chance of getting it back?
'Hide thread' feature (kbin.social)
Are there plans for a 'hide thread' feature, under 'more'? (next to comment and boost)...
Option to put thread comment box above existing comments? (kbin.social)
As scrolling to the bottom of the page to leave a comment can be a hassle on posts with lots of existing comments, an option to put the thread comment box above existing comments would be helpful....