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.

[kerryarchibald]

@clokep / @daniellekirkwood do we care about backwards compatible support for the unstable identifiers? Ie do we need to support both org.matrix.msc3952.* and m.* on EW? AFAIK intentional mentions has not been released/available on mainline so the impact of abandoning the unstable identifier would be minimal.

[clokep]

@clokep / @daniellekirkwood do we care about backwards compatible support for the unstable identifiers? Ie do we need to support both org.matrix.msc3952.* and m.* on EW? AFAIK intentional mentions has not been released/available on mainline so the impact of abandoning the unstable identifier would be minimal.

I was not planning to maintain any backwards compatibility on the server. I think impact is minimal and not worth it.

[daniellekirkwood]

Happy with that ☝️

[clokep]

@giomfo suggested that we likely want to do something to handle migrating of disabled push rules so that users don't just have mentions enabled by this work if they had previously disabled them. this sounds reasonable (although I have not yet investigated how hard it would be to do). From discussion we came up with:

• If .m.rule.roomnotif is disabled, then disable .m.rule.is_room_mention
• If both .m.rule.contains_display_name and .m.rule.contains_user_name are disabled, then disable .m.rule.is_user_mention

For the second bullet, the thought was that if a single one of them is disabled the user is likely trying to get around the "unintentional" behavior we're fixing, but if they're both disabled then they really don't want mentions. This still might be overly aggressive, but a user can always re-enable it manually in the future.

@daniellekirkwood does this sound good to you? I can look at implementing before stabilizing.

[daniellekirkwood]

Yes, sounds good to me.

Good catch both! Thank you

[clokep]

Cross-linking support for other projects (which isn't a blocker, but nice to have all in one spot):

• Support MSC3952 intentional mentions element-android#8489
• Support MSC3952 intentional mentions element-ios#7567
• push: Add support for intentional mentions push rules  ruma/ruma#1550 / Implement Matrix v1.7 changes ruma/ruma#1520

[clokep]

@daniellekirkwood Should we consider this done?

[daniellekirkwood]

@daniellekirkwood Should we consider this done?

YES 🕺