remove unused `dont_notify` and `coalesce` push actions

[richvdh]

cf: https://matrix.org/docs/spec/client_server/r0.6.1#actions. dont_notify is a no-op and its presence causes confusion. coalesce has never been implemented afaik

[richvdh]

also in the cleaning-up-pushrules arena: #637

[richvdh]

for reference: these actions both date back to matrix-org/matrix-spec-proposals#10. I think they are relics of an early draft which never got cleaned up.

[ara4n]

dont_notify is not a no-op - it's a means of telling the evaluator to stop executing rules when it hits a matching rule with action dont_notify. I guess your point is that you could just leave the actions empty for this situation (given we default to not sending a notif), but I'd be concerned that in reality we have a tonne of these actions in the wild already, and explicitly spelling out that the action expected by matching a rule is not to notify may not be a bad thing.

curl -s 'https://matrix.org/_matrix/client/r0/pushrules/' -H "Authorization: Bearer $at" | grep -c dont_notify
102

[ara4n]

the rationale for coalesce's existence is that we had this functionality pre-Matrix in Amdocs UC and it was actually quite useful - beyond a given threshold we'd start saying "206 more messages in #foo" rather than sending 206 pushes in a row. It obviously hasn't been fleshed out here though, but I wonder whether we should at least reserve the keyword for things like this, even if it hasn't been fleshed out.

[turt2live]

given we gatekeep the spec and require the use of namespaces for custom implementations, do we need to reserve the keyword?

[richvdh]

dont_notify is not a no-op

Unless I'm misunderstanding how the rules work - in which case, I would be delighted to be corrected - it is absolutely a no-op. Including it in the list has absolutely no effect. It's even valid to have a push rule with both notify and dont_notify (which, because dont_notify has no effect, is the same as notify).

Now, there may be an argument for having a specified no-op, but: it is a no-op.

I guess your point is that you could just leave the actions empty for this situation (given we default to not sending a notif),

That is exactly my point, and I contend that its very existence is a source of confusion, since it leads to the questions of "when do I need to set it? what happens if I don't set it? Is it a no-op or not?"

but I'd be concerned that in reality we have a tonne of these actions in the wild already

Well, I wouldn't propose forbidding its use: just marking it deprecated.

and explicitly spelling out that the action expected by matching a rule is not to notify may not be a bad thing.

I think it would be less of a bad thing if clients had do to it: which is to say that for a rule to be valid, it has to either specify notify or dont_notify. But the fact is that this is not currently enforced, leaving us to support a mix of some rules where dont_notify is explicit and some where it's left implicit.

At the very least, the spec should make clear that it is a no-op. But I think we can go further.

[auscompgeek]

dont_notify is used in matrix-org/matrix-spec-proposals#2153.

[richvdh]

dont_notify is used in matrix-org/matrix-spec-proposals#2153.

yes, but not in a way that makes any material difference here.