Remove unintentional pings

[daniellekirkwood]

Your use case

This is a meta issue that contains and concerns the work being undertaken to decide and implement the correct activity when a user's display name is used in message content.

A users display name should not cause a ping (and today is does). Pings should always be intentional and obvious (maybe through pills).

---

Here are related bugs:

• Notified on string that's a substring of my full displayname element-web#6307

---

In the Delight team roadmap, "Remove unintentional pings" has 3 line items:

• Remove the ping when a users display name is written in the timeline. Pings should only occur when a user is ""@"
• Reactions, poll messages, room events should not ping a user or leave a notification unread in their room list

[daniellekirkwood]

@clokep assigning you as you're currently the driver for this. Let me know if you need any product input.

[clokep]

There's a bunch of other cases document in the spec repo (or as part of MSCs):

• Replying to a message will re-issue pings from the initial message due to fallback replies. (MSC2781 proposes removing reply fallbacks which would solve this problem, although as noted in MSC3676 this may require landing MSC3664 in order to receive notifications of replies.)
• Each message edit will be re-evaluated for pings.
• Pings occurring in spoiler contents or code blocks are evaluated.
• If the localpart of your Matrix ID is a common word then the .m.rule.contains_user_name rule matches frequently (e.g. Travis CI matching @travis:example.com).
• If the localpart or display name of your Matrix ID matches the hostname (e.g. @example:example.com receives notifications whenever @foo:example.com is replied to).

If folks know of other cases I would like to hear about them!

[clokep]

See MSC3952.

[clokep]

I removed #901 from the description of this issue -- it is only vaguely related.

[clokep]

MSC3952 has been accepted into the spec, but there's some remaining work to get this in front of users:

• Stabilize support for MSC3952: intentional mentions matrix-org/synapse#15487
• Stabilize support for MSC3952: intentional mentions element-web#25267

The bulk of that work is switching from unstable identifiers (org.matrix.msc3952.* to m.*) and enabling the features by default. As mentioned in the MSC, backwards compatibility between clients and/or servers that are using the legacy rules vs. the new rules should not be an issue most of the time.

Note that Element Web manually pulls push rules before each sync so it should immediately find out about these push rules when they're enabled on a homeserver. Additionally it Element Web uses a server flag to decide whether to enable the feature or not, although I'm not really sure this is necessary.

I think this essentially means we can enable the backend and frontend completely separately.