Mastodon: Fix filtering (move away from regex)

[ghost]

Hello everyone !

It would be nice for non tech people to put a link to a regex tutorial somewhere to help them use the regex filter. It would make thing really easier for them.

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[ghost]

Better to replace the regex thing with two simple "exclude these words/phrases", "include these words/phrases" textboxes so non-programmers (the vast majority of users) don't have to learn what the *beep* is meant by a "regular expression". For the few programmers among the audience you can add a note that it also accepts regexes and they'll know what those are without a tutorial.

[jckw]

I agree with @Kimik0. Regex could be kept available but the majority of users probably wouldn't bother following a regex tutorial just to filter toots, and they don't need that sort of complexity/ flexibility.

Changing this to be keyword entry, or just a comma-separated list would make more sense usability-wise.

[ghost]

Yes I totally agree with you. It was more of a first step thing which need less work than changing the way the filtering works now.
As it would be faster and easier to just add a line with a link to a tuto than to rework the way the filtering is done.

[Aldarone]

I think it might be the time to bump this.

And here is what I think about it :

• Per column filtering is confusing for people and I'm not sure there are many use cases where this feature is really needed and that justify the need of duplicating some regex in three different input fields.
• Everyone agree that regex is hard and « YOU SHOULDN'T HAVE TO KNOW PROGRAMMING TO FILTER YOUR TIMELINE OUT »
• But I'd be sad if we'd drop them because they're so very powerfull

What I suggest is making a new « Parameters page » or a new tab in the web client to manage filters.

It would feature a list of filtered things with the ability to delete them and to add new ones but here is the catch : Internally it would be dealt with like a regex. Concatenate every muted thing by separating them with | and putting that in the filter engine.

If the user don't know regex, they'd enter one word at a time. If the user know regex they still can enter many of them.

So in the webclient we'd show something like this :

• random
• negative
• word
• that
• needs
• to be
• filtered
• (\b[A-Z]{3,}\b\s*){3,}
• (^|\W)%\w+
• [Add a new one here]

And the resulting regex used by Mastodon is : random|negative|word|that|needs|to be|filtered|(\b[A-Z]{3,}\b\s*){3,}|(^|\W)%\w+

The best of the two world.

As a bonus point, we could detect if a field matches [\w ] and change random as [^|\W]random\W in the final regex to get full word matching.

What do you think ?

[Laurelai]

Bumping this to say that regular users should not have to know regex to filter things out. This is a major accessibility issue.

[davegregg]

There would have to be some sort of delineation between dumb text and regex strings. You don't want someone looking to filter qua.com to end up matching qualcomm.

Perhaps a tickbox to enable regex for a particular filter, or required delimiters, like the classic /regexhere/ (where not preceded by an r, lest we match subreddit names). The latter would be my recommendation to keep the clutter of a tickbox off the page and keep with the regex delimiter convention.

[nightpool]

Since noone seems to have updated the github thread (our bad), this is on our immediate roadmap for new features post-2.1 and has been for a couple weeks.

[nightpool]

duplicate of https://github.com/tootsuite/mastodon/issues/1158 (although this one has more discussion, not sure which to keep)

[deutrino]

I'd like to call particular attention to the request that this work for CWs in some way, as requested in #4081.

[forty8bits]

Per column filtering is confusing for people and I'm not sure there are many use cases where this feature is really needed and that justify the need of duplicating some regex in three different input fields.

I wonder if it's worth splitting this out into a separate issue, as it seems like potentially low-hanging fruit and a decent UX improvement?

[lyndsysimon]

I'd like to suggest leaving the existing regex functionality, but making either plain text or a simple query language the default. For example, to filter out foo and bar from a timeline: foo bar. If you want to use a regex to filter bar and baz: /ba[rz]/

In short, if the filter is surrounded by /s, treat it like a regex. If it's not, treat it as a "simple" filter.

This would of course require escaping _literal_ forward slashed inside a regex, but that should be doable.

[forty8bits]

@lyndsysimon I think in that case we'd be adding complexity for no real gain; we could just tell users to separate terms by | instead of space or comma and everything would work with the current regular expression functionality. The user wouldn't even have to know anything about regular expressions, just that they need to use that weird | character.

[lyndsysimon]

I'm very familiar with regex, but not with Mastodon's functionality yet. Wouldn't my proposal help with all sorts of edge cases where characters have specific meanings?

FWIW, I've not yet found any documentation for how the filters are applied...

[forty8bits]

Yes, you're right actually @lyndsysimon, my point was naive; leaving as raw regular expressions would mean the various characters with special meaning in regular expressions would be a problem and inevitably trip people up.