Why YSK: Certain topics are stressful and tend to spread all over the site, including to unrelated communities. Blocking communities can be overkill and ineffective, and likewise for blocking individual users.

To do so, open up the uBlock Origin dashboard, go to the ‘My filters’ tab, and add this filter:

lemmy.world##article.row:has-text(/word1|word2|word3|word4/i)

For example:

lemmy.world##article.row:has-text(/Trump|Elon|Musk|nazi/i)

Then apply the changes and reload any open tabs, and all posts which contain any of your filtered words will simply not show up.

You’ll have to change “lemmy.world” at the start to whatever your actual instance is. You can filter as many or as few words as you want, just keep the / at the start, the /i at the end, and separate words with | pipes. What’s actually being filtered is a case-insensitive regex, if you want to get fancy with it.

Here are equivalent filters for reddit and Ars Technica:

reddit.com##div.thing[data-context="listing"]:has-text(/word1|word2|word3|word4/i)
arstechnica.com##article:has-text(/word1|word2|word3|word4/i)

As a disclaimer, I made these myself, and I’m not particularly familiar with creating uBlock Origin filters. There may be better ways to do this. Also the reddit one is specific to old.reddit.com, and the lemmy filter is made to work with the default lemmy.world web UI and may not work on other UIs without tinkering.

Yes, I know I’m just hiding my head in the sand.

  • zkfcfbzr@lemmy.worldOPEnglish
    4·
    2 days ago

    Hey! I’m pretty sure this one will work:

    infosec.pub##:not(a.community-link:matches-attr(title=/.*?leopard.*?/i)) article.row:has-text(/Trump|Elon|Musk|nazi/i):not(:has-text(/leopard/i))

    Where now we have three filters. If the community name matches the first regex, then nothing at all will be filtered out - and then the other two work the same as before. So any post that matches the blacklist regex will be filtered out unless it also matches the whitelist regex.

    I chose to make the first regex /.*?leopard.*?/i because my thinking is you may want to just copy/paste the other whitelist filter there for simplicity, but it might make more sense to do it like the others, like /leopardsatemyface|second community|third community|etc/i. The “title” of a community for the purpose of this filter should be whatever appears after /c/ in the URL, not counting the @lemmy.world (or whatever instance) part.

    • dmtalon@infosec.pub
      3·
      2 days ago

      So, within the code snippet above, that line is not working with the .*?leopard.*? but when I swapped in the community name leopardsatemyface it seems to work as expected.

      Within the community I see trump posts, and within the main feed I do not. I need to see if a trump post from that community bleeds through to my main feed. I’m watching for that.

      • zkfcfbzr@lemmy.worldOPEnglish
        1·
        2 days ago

        What happened with .*?leopard.*?? It was still filtering Trump posts even from the community page? My own testing showed that variant working - I never actually even tested the leopardsatemyface variant

        To be clear, this filter should allow for Trump posts that mention leopards or come from that community to show up on your main feed - that’s what’s desired here, right?

        It also occurs to me that the ? on the .*? isn’t necessary - even just .*leopard.* should work as expected

        • dmtalon@infosec.pub
          1·
          2 days ago

          It was not filtering trump from my main feed. Sorry I should have explained “not working” better in my reply :)

          • zkfcfbzr@lemmy.worldOPEnglish
            2·
            1 day ago

            Hello again 🙂 I have a good feeling about this one.

            infosec.pub##:not(head>title:has-text(/leopard/i)) article.row:has-text(/Trump|Elon|Musk|nazi/i):not(:has-text(/leopard/i))

            It’s doing basically the same thing as the last one but now instead of targeting an <a> tag with the community-link attribute, which was basically just the first way I was able to find of identifying a community last time, it targets the title of the page itself, which seems like it should be a lot more reliable. This does mean using the literal leopardsatemyface-type filter won’t work since the title of the page is the community’s user-friendly name: “Leopards Ate My Face” in this case.

            So as before it should block any posts which contain words from the blacklist, unless they also contain words from the whitelist - and now if the title of the page has any words from the whitelist (indicating we’re on an allowed community page), it will block nothing at all. The blacklist and whitelist will apply to the post title, community name, and even the submitter’s name - anything you can read and even some things you can’t read.

            • dmtalon@infosec.pub
              2·
              13 hours ago

              I’ll check it out for sure and get back to you! It is nice cleaning up my feeds. I use boost on my phone and while I can’t limit filters like this it sure has cleaned up my feed there too.

          • zkfcfbzr@lemmy.worldOPEnglish
            2·
            1 day ago

            I think I may see why. I didn’t actually bother to check the main feed before, but it seems like it does have the a.community-link tag the new filter targets in every post - so if a post from leopardsatemyface ever shows up in the main feed, then the filter will think it’s on that community page and fail to block any posts. But the filter should work fine so long as no posts from that community are currently on the main feed. This should be the case regardless of which regex is used - if it wasn’t just a coincidence earlier I’ll have to test around to figure out what happened with that.

            It’s a process making a good filter, I guess - I may look into a more reliable and narrower way to achieve the desired effect later on