Notifications: do not look for keywords in MXIDs

[pacien]

Unintended notifications/highlights/mentions are generated by messages containing MXIDs having substrings matching someone else's username, display name, or user-defined keywords.

MXIDs strings should be excluded when scanning a message's body for mentions using keywords. It makes no sense to try to find a substring in those as they already are explicit mentions as a whole, targeting the current user or someone else.

Example of problematic case

Username in homeserver domain

My username matches my domain (MXID of the form @<username>:<username>.tld).
As a result, all replies to messages from any other user on my homeserver are highlighted in my Riot session, flooding me with urgent notifications without intended mentions.

Let @alice:alice.tld, @bob:alice.tld and @caroline:alice.tld be three users on the homeserver alice.tld. All three are members of a room in which:

1. Bob sends a message that does not mention Alice.
2. Caroline replies to Bob's message using the reply feature, still not mentionning Alice.
3. Alice's Riot highlights Caroline's message and Alice is notified, even though nobody intended to mention her. This is because Caroline's message text representation contains <@bob:alice.tld>, which matches Alice's username alice.

Username substring of another username

I haven't tested it, but the issue may probably also arise when someone's username is an infix of someone else's username: @pierre:somedomain.tld might get notified when someone replies to a message from @jean.pierre:otherdomain.tld. To confirm.

---

This issue has been previously reported as element-hq/element-web#11132 and matrix-org/synapse#6202, but seems to be a spec issue more than an implementation issue.

[richvdh]

matrix-org/matrix-spec-proposals#2463 proposes a solution to this.

[JokerGermany]

anything new regarding this?

[ShadowJonathan]

2c: I'm actually using this feature (keyword matching) to make sure my MXID is always pinged, as i've disabled pings for my username (as it is too easily pinged with my domain)

[clokep]

Note that I marked MSC3952 as fixing this as I'm fairly certain the original report isn't actually about keyword matching, but about the .m.rule.contains_user_name which matches the current user's localpart against the content of each message. (This matches the example given above where @alice:alice.tld.

You could set a custom keyword for this, but in that case I think this is somewhat expect behavior.

Note that MSC3952 deprecates the above rule so for most users it shouldn't be an issue. If you're setting a keyword which happens to match your localpart and your homeserver's hostname; I'd argue it should match on all those messages since generally full MXIDs aren't placed in the plain text version of messages.

---

tl;dr From my reading of this, I think that MSC3952 fixes this, but I may be wrong! If I am let's reopen this and clarify the above!