search

mastodon / mastodon

Your self-hosted, globally interconnected microblogging community
https://joinmastodon.org
GNU Affero General Public License v3.0
46.34k stars 6.79k forks source link

Revamp filters to cover more use cases #18955

Open trwnh opened 1 year ago

trwnh commented 1 year ago

Pitch

  1. filter based on
    • status content / cw / alt text contains substring
    • author username/domain contains substring
    • author id
    • conversation id
    • attachment type? (sensitive, no alt text, image/video/poll, etc)
    • filter on hashtags (outside of content)
    • filter on mentions (outside of content)

1a. filter content by

  1. filter in context of

    • home timeline
    • public timelines
    • notifications
    • profiles
    • conversations
    • specific list
    • specific author

  2. filter with behavior:

    • hide entirely
    • hide with reason shown
    • hide with reason shown and allow expansion
    • hide content and attachments only
    • hide images/attachments only

  3. filter for duration

    • infinite
    • expires at specific time
    • expires in certain duration

  4. add a note or description

Motivation

18035 doesn't go far enough imo

tangential issues:

etc

spitballing a bit, could be broken down into categories like "keyword mutes", "user mutes", "conversation mutes" and you could sort your filters for just that category

optional extension of this feature request: subsuming user mutes and conversation mutes into a server-side filtering mechanism. you could keep the user-facing functions to mute a user or convo but it would map onto the filter system in the backend

ClearlyClaire commented 1 year ago

I think the current iteration of the filters system covers most of what you've requested, and the ship for a global redesign has sailed.

Regexps were ruled out both because it would be hard to make it user-friendly, and because it is relatively easy to make expensive regexps, which is not an option as filters are applied server-side. That second issue doesn't apply to simple boolean logic, but I'm afraid designing a satisfying user interface would be pretty complicated.

I'm not too sure what would be the value of “hide with reason shown” without the option to expand the post, but this could be added. By the guidelines set in #18058, clients not supporting this would handle it as “hide with reason shown and allow expansion”.

The whole “filter duration” thing is purely an interface thing (but I agree that ideally we should improve that bit of the filter management interface).

trwnh commented 1 year ago

the ship for a global redesign has sailed.

well, i suppose i'd still keep this issue open, i'd just punt it down the road to the further future if/when large refactors are being considered.

Regexps were ruled out both because it would be hard to make it user-friendly, and because it is relatively easy to make expensive regexps, which is not an option as filters are applied server-side.

user-friendliness i'm not sure matters, because if you write a regex you know what you're getting into, but i understand that expensiveness is a real concern for server-side processing.

I'm not too sure what would be the value of “hide with reason shown” without the option to expand the post

i mostly included it for completeness -- if it's deemed not useful or important enough to include, then i don't particularly care

I think the current iteration of the filters system covers most of what you've requested

this is where i would have to disagree. contexts are not granular enough, the only boolean logic supported is OR, it's not possible iirc to mute by username/domain/display name/attachment/conversation (at least not in a centralized place for that last one), and there's no way to add a note

of course there's room for future incremental improvement, but the main concern i see with the way the filter system is going is that the workflow is a bit complicated. rather than treating this issue as a collection of loose feature requests (as the tangential issues list, essentially), it would make more sense to have a UX rethink around the concept of filters/mutes and make the whole system more modular. the surface area is larger than just the existing filters feature -- there are a lot of slightly disparate issues that could be addressed by unifying similar yet distinct features within the same interface (or at least within the same tab in settings). the scope of user mutes is a good example of how inflexible the current feature is; it's been changed multiple times and still can't address user expectations consistently and universally. it would make more sense to have a generic filter against an account ID and define the contexts myself rather than having the "too powerful" current behavior; basically, i get to define exactly how powerful the mute is for myself. how that gets exposed UX-wise via the "mute" button or dialog or API parameters is a separate thing entirely.

i know the following use cases right now are not covered:

there is a lot of flexibility that is easily covered by a generic filter system and not as easily covered by just making more and more features.

ClearlyClaire commented 1 year ago

I think the current iteration of the filters system covers most of what you've requested

this is where i would have to disagree. contexts are not granular enough, the only boolean logic supported is OR, it's not possible iirc to mute by username/domain/display name/attachment/conversation (at least not in a centralized place for that last one), and there's no way to add a note

of course there's room for future incremental improvement, but the main concern i see with the way the filter system is going is that the workflow is a bit complicated.

I fail to see how your proposal would simplify this.

i know the following use cases right now are not covered:

* mute this conversation, but not hide it entirely

This is something I'm considering, and it would work like #18945. The main issues are around listing the filtered conversations for later review/editing, both from an UX standpoint and an implementation one (currently, posts are not indexed on conversation ID).

* mute a user, but not all mentions of them

This could be done by having a “mention” filter type and having the default mute functionality not filter mentions out. But I'm not sure this is worth it, and we'd need to be careful about providing a migration path.

* mute all users from a certain domain

Could be another type of filter in the existing framework, but I'm not sure it's worth it.

* mute this keyword, but only if posted by a certain user

* mute a user in the home timeline but not in lists

Those would probably need deeper changes indeed.

MasonProtter commented 1 year ago

One thing the Filter system seems to not support is filtering all the replies to a filtered post.

I just had a situation where three people I follow had a very in-depth conversation on a topic that doesn't interest me, all replying to eachother and it filled up a very long chunk of my timeline.

As far as I can tell, my only options here would be to

1) Unfollow them which I don't want to do 2) Go through and manually filter every single one of their posts which is too much work to be worth it 3) Deal with it which is what I'm going to do, but this makes me apprehensive about following too many people, especially active people.

trwnh commented 1 year ago

As stated earlier, it is currently not possible to filter by:

What you ask for could be conceived as FilterConversation where you could make a filter group check for conversation ID instead of having to manually filter every single status as new ones get posted, yeah

MasonProtter commented 1 year ago

Yes, to be clear I was requesting a specific feature that I think was encompassed by this issue, but I think it's important to have a user friendly easy way to do this.

zecamigo commented 1 year ago

Adding suggestion

  1. Filter based on :
    • Specific list(s)
tgt commented 1 year ago

I'd often like to know the author / booster of a hidden post before deciding whether or not to expand it. So a suggestion:

  1. filter with behavior:
joyeusenoelle commented 1 year ago

One more suggestion: filters do not currently seem to match diacritical variants. For example, if I have a filter for "pokemon", and a post reaches my timeline containing the word "pokémon", that post will not be filtered. I suggest that filters have a toggle for whether they should check for diacritical variants (as diacritical marks can change the meaning of a word in some languages); i18n.transliterate() may be helpful here.

BMaxV commented 1 year ago

I have more suggestions for the list above.

I want to limit the frequency of very busy accounts. Some news outlets have a behavior of releasing things in 5m, 10m or 30m intervals. This drowns smaller, but valuable voices.

These issues mention a "rate limit" and a frequency filter.

https://github.com/mastodon/mastodon/issues/22537 https://github.com/mastodon/mastodon/issues/22898

During my search I also found this one that's relevant to the topic but not in your list, about filtering posts by "account quality" e.g. no accounts younger than x days :

https://github.com/mastodon/mastodon/issues/12181

sayunuh commented 7 months ago 
* mute all users from a certain domain

Could be another type of filter in the existing framework, but I'm not sure it's worth it.

Users on our server really want this feature to be implemented. Users should be given options to deal with remote posts that they find uninteresting, other than just outright blocking the entire server. Some of us use domain blocking just to avoid seeing posts from a particular server on the federated timeline, which is too harsh for the desired effect, but I cannot stop them because there is no other way. What’s needed for the use case is just a simple exact match of a domain name as a filter condition, no fancy wildcards or compound conditions.

timtfj commented 6 months ago
  • mute this keyword, but only if posted by a certain user

This is a really important one. Probably in the form "any of these keywords, posted by any of these users".

Squaredude commented 2 months ago

boolean logic (AND OR NOT)

I'm surprised that the current system doesn't at least offer this. Currently it's all OR. With even just adding AND and NOT, it would provide a lot more flexibility to the filtering system.

ThisIsMissEm commented 1 month ago

a small thing to note here: we need to implement the filtering logic in both Ruby and in the Streaming server (JavaScript), so more options mean much more complexity at a feature complexity x 2 when implemented