Consider making push rules actually turing complete

[turt2live]

Aside from the joke, we might want to consider a DSL (Domain Specific Language( of some kind to represent push rules, making it easier to upgrade push rule conditions without servers having to guess at client support.

For example, both matrix-org/matrix-spec-proposals#3758 and matrix-org/matrix-spec-proposals#3862 would be much easier if we could just add a block of DSL code to the server and sync it to the client: we might not even need an MSC, and it'd Just Work™.

Downside obviously being that something as "simple" as notifications could do simple mathematics and possibly hold a conversation with enough effort. However, it might also be good(?) if some server out there wants to start running simple machine learning-based notifications: serialize your model down to the DSL and feed it through a client.

[richvdh]

given calculating push on the server is already very CPU-intensive, this doesn't sound like a great idea to me.

[uhoreg]

I don't know what kind of DSL you're thinking of, but I've been working on a personal project that involves pattern-matching Matrix events. The full syntax is probably overkill for notifications, but to throw yet another idea out there, the general idea is:

A pattern matches a value depending on what the pattern is:

• it is a string, integer, boolean, or null, and the value is equal to the pattern

• it is an array, and the value is an array of the same size, where each element in the pattern is another pattern that recursively matches the corresponding element in the value

• it is an object where, for all of the pattern's fields:

  • if the field's name does not start with an underscore and the value is also an object, it is a pattern that recursively matches the corresponding field in the value.
  • if the field's name starts with a double-underscore (__) and the value is also an object, it is a pattern that recursively matches the field in the value with the same name, but with one underscore removed. For example, a pattern with a field of __foo would match against the _foo field in the value.
  • if the field's name begins with a single underscore, then the pattern matches depending on the field name:
    • _any: matches any value. The field's value is ignored, but is usually 1 by convention. This could be used, for example, to ensure that a field is present, without restricting its value. e.g. {"foo": {"_any": 1}} would match {"foo": "bar"}
    • _or: is an array of sub-patterns. The pattern matches if any of the sub-patterns matches. e.g. {"_or": [1, true]} will match 1 and true
    • _and: is an array of sub-patterns. The pattern matches if all of the sub-patterns match.
    • _not: matches if the value does not match the field's value. e.g. {"_not": 1} will match everything except for 1
    • _regexp: matches if the value matches the regular expression given in the field's value.
    • _contains: matches if the value is an array that contains an element that matches the field's value. e.g. {"_contains": 1} will match [0, 1, 2]