event_match key in push rule conditions does not cater for field names with dots

[richvdh]

https://matrix.org/docs/spec/client_server/r0.6.1#conditions says:

key The dot-separated field of the event to match, e.g. content.body

Various standard event fields (notably those in matrix-org/matrix-spec-proposals#1849) have dots in their names. It's unclear how these are handled.

[richvdh]

In practice, it looks like {"key": "m.foo", pattern: "bar"} will match both:

{
    "m": { "foo": "bar" }
}

and

{
    "m.foo": "bar"
}

[richvdh]

related: matrix-org/matrix-spec-proposals#2637

[t3chguy]

What will it match in the case of ambiguity?

{
    "m": { "foo": "bar" },
    "m.foo": "baz"
}

[richvdh]

IT DEPENDS 🎉

depends what order python decides to go through the dictionary, which is probably ultimately determined by the order they arrive over the wire from the client.

so that's fun.

[jplatte]

Could we just deprecate the "dot-separated" in

key The dot-separated field of the event to match, e.g. content.body

?

[t3chguy]

How would you refer to match content.body then?

[jplatte]

Well, like in your example,

{
    "content": { "body": "foo" }
}

[t3chguy]

My example is of an event body, how would you refer to it in the key string for the push rule which is what this issue is about?

[jplatte]

Okay, I misunderstood then. In that case, and if we want to continue only matching on one key (which is probably a good idea, otherwise we'd open another can of worms), maybe we could adopt JSON pointers? That would make the implementation much more straight-forward, though we'd have to figure out the compatibility story for that.

[richvdh]

yeah the problem is that we could do any number of better things, but it's going to be hard to maintain compatibility. Ultimately servers are probably going to have to support either of two formats. Meanwhile it's more of a wart than a practical problem.