Add a way to escape glob characters

[uhoreg]

There is currently no way to match a literal * or ? with a glob pattern without matching other things as well. So it is not possible, for example, to apply a policy rule to a user with ID @*:example.org without it applying to other users as well.

One possibility would be to allow backslash-escaping.

(This came up in a discussion on MSC4155)

[turt2live]

A bit of history: Escaping was considered around the time of MSC2313 Policy Lists (merged), but was largely written off for a few reasons:

1. Server ACLs didn't specify such a mechanism, and reuse was important for code efficiency.
2. Escaping mechanisms quickly become complicated for inequal gain. Suddenly, the system needs to consider escaping the escape sequences, invalid escapes, behaviour attached to each, etc.
3. There didn't appear to be a particularly strong use case to support escapes. While it's true that user IDs in particular can contain the matching characters, it's always felt like it's wrong that IDs can do that. Instead, approaches like MSC4044 and MSC4243 are believed to be superior because they either remove the conflict directly or introduce mechanisms which make the conflict impossible (ie: by using keys as localparts).

I'm not sure if server ACLs similarly considered escape sequences while they were being introduced - I can't readily find history on this particular feature at the time of writing.

In my opinion, a proposal to introduce escape sequences will need to have a strong use case for doing so. We've gone 6+ years without them, so it's hard for me to get behind the argument that they should "just exist".

For links, this was previously discussed at #2156

[Johennes]

I'm not sure if server ACLs similarly considered escape sequences while they were being introduced - I can't readily find history on this particular feature at the time of writing.

I believe server ACLs don't require any escaping because * and ? are not allowed characters in server names.

Apart from policy rules, globs are currently also used in event_match push rule conditions. The result is that you cannot match literal * and ? characters in any event content field.

It seems odd to me that we would define our own globbing style without the possibility of escapes and then use it in situations where the unescapable control characters can occur – however likely that may be.

As an example, POSIX defines escapes in a seemingly straightforward manner:

A character shall escape the following character. The escaping shall be discarded. If a pattern ends with an unescaped , it is unspecified whether the pattern does not match anything or the pattern is treated as invalid.

Clients will most likely not implement globbing themselves but just resort to a library. So the complexity of evaluating glob expressions seems somewhat secondary to me.