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.
And it’ll be faster and more efficient to do it server side as opposed to making uBlock Origin handle it.
I think it’s better to use distributed filtering than having their SQL query do additional filtering. Every user who uses filtering adds to the lifting their side has to do - while your CPU probably sits under 1% utilization most of the time.
I’d rather Lemmy have filtering on the client-side, and just shoot us raw data.
Not all filtering is the same. Client side filtering requires more data to passed over the network that then just gets dropped. It also means rules that are not shared across devices.
Most importantly, these use CSS filters which are computationally more expensive because it has to take an entire DOM element, serialize it to text, string search it vs a server side filter that can just look at a one or two field variables. Even if it’s not filtered in SQL on Lemmy’s side I’d say it’s still more efficient overall.
You do what you want, but adding extra work on the client side is not what I’d want for my users. Of course, if your Lemmy instance does not supporting filtering, then this is moot.