MSC3517: "Mention" Pushrule

[ShadowJonathan]

Rendered

Signed-off-by: Jonathan de Jong <jonathan@automatia.nl>

Related: matrix-org/matrix-spec#353

---

Preview: https://pr3517--matrix-org-previews.netlify.app

[uhoreg]

I've marked this as kind:maintenance because it feels to me like just an update to push rules, rather than a new feature. But someone who's more familiar with push rules can feel free to disagree with me and change it to kind:feature.

[ShadowJonathan]

I've marked this as kind:maintenance

It was completely intended like that, thanks enough though.

[richvdh]

related: matrix-org/matrix-spec#353, #2463

[richvdh]

maybe. Updating the default push rules is a lot harder than just adding a new rule - you've only thought about the easy bits ;)

[richvdh]

I think we can guess, but where in the list of predefined push rules should this be inserted?

[richvdh]

... and do we keep or get rid of the existing mention rules?

[ShadowJonathan]

Imo, keep the existing mention rules (displayname, username), as i know they're quite useful for some other users, this is just about adding additional options. We can bikeshed about un-defaulting them or removing them later (in another MSC).

[richvdh]

we need to specify a whole lot of detail about migrations:

• what should servers do for existing users? should they add the new rule in, or not? if so, should they consider whether the user has changed the default settings for other rules?
• How should a client behave when it encounters a user without the new rule? It may depend on whether the server supports the new rule or not.
• How should the server behave when a client tries to modify the existing displayname/localpart mention rules? should it magically update the new rule?

[ShadowJonathan]

Good point, the conservative approach would be to disable this, and let clients detect and auto-enable this.

However, that would just shove the problem to clients, and it doesn't tell anything about what if client A doesnt "know" this push rule, and B does, and enables it.

The alternative (just enabling this) would exacerbate the above problem.

---

I think, this being default-on (atm), that the server should just enable this once it encounters a user without this push-rule installed, be it that it lazily detects this upon push-rule changes, or as a background job when booting into the new version.

I do think that, if this was enabled while unstable, the server should first try to migrate over the unstable prefix, instead of defaulting and auto-enabling (as it could be quite annoying for some users)

Or, while the rule is unstable, the rule should be non-default, this could give a grace period in which clients and servers learn of this rule, before it switches to stable and becomes default-on.

[ShadowJonathan]

I want to deprecate this MSC in favour of MSC3952.

This MSC wasn't ever meant to fully solve the problem, but to wedge a solution in that would alleviate a large annoyance today, but I see MSC3952 solving this problem completely. Secondly, MSC3952 also templates exactly what I saw in a "follow up" or "more serious" MSC after this one, so having this superseded in favour of it is logical.