matrix-doc/proposals/4210-remove-legacy-mentions.md

2.3 KiB

MSC4210: Remove legacy mentions

Matrix v1.7 introduced intentional mentions, where events list users they mention explicitly, instead of the recipients inferring mentions from the raw message text. For backwards-compatibility reasons, messages without the new m.mentions field still use the old plaintext matching for mentions.

Plaintext matching means it's very difficult for automated tools to tell which users are mentioned in a message. This means that it's easy to spam mentions by simply not using intentional mentions.

If intentional mentions are mandatory, automated tools could easily ban users who send more than X mentions in a single message. There could even be a new push rule condition to allow checking the number of mentioned users and skip notifying entirely.

Proposal

Support for legacy mentions is dropped. Specifically, the following deprecated standard push rules are removed entirely:

  • .m.rule.contains_display_name
  • .m.rule.contains_user_name
  • .m.rule.roomnotif

Additionally, the contains_display_name push rule condition is deprecated.

Including an empty m.mentions key is still required for clients that are aware of intentional mentions, as omitting it would cause current clients to assume messages are not using intentional mentions.

Potential issues

Users using old clients (which don't send intentional mentions) will no longer be able to mention users on up-to-date clients/servers.

Users using old clients (which don't support the new push rule conditions) will also no longer be notified for mentions in case the client depends on the push rules served by the server.

Alternatives

The removal could be done in a new room version, such as when switching to extensible events, as suggested by MSC3952. However, such a migration will likely take much longer than clients implementing intentional mentions. Additionally, the room upgrade UX is still an open issue, which means many rooms simply don't upgrade. Therefore, making a slightly breaking change to existing room versions seems like the better option.

Security considerations

This proposal doesn't add any features, so there are no new security considerations.

Unstable prefix

Not applicable, this proposal only removes features.

Dependencies

None.