matrix-spec-proposals/proposals/3958-suppress-notifications-of-message-edits.md

MSC3958: Suppress notifications from message edits

Event replacement (more commonly known as message edits) signals that a message is intended to be replaced with new content.

This works well for fixing typos or other minor correction, but can cause spurious notifications if the event mentions a user's display name / localpart or if it includes @room (which is particularly bad in large rooms as every user is re-notified). This contributes to notification fatigue as the additional notifications contain no new information.

Additionally for users which have a room set to "all messages" then every event edit results in an additional notification.¹

Proposal

A new default push rule is added to suppress notifications due to edits.

{
    "rule_id": ".m.rule.suppress_edits",
    "default": true,
    "enabled": true,
    "conditions": [
        {
            "kind": "event_property_is",
            "key": "content.m\\.relates_to.rel_type",
            "value": "m.replace"
        }
    ],
    "actions": []
}

This rule should be placed after the .m.rule.room.server_acl rule as the last override rule.

It would match events such as those given in event replacements portion of the spec:

{
    "type": "m.room.message",
    "content": {
        "body": "* Hello! My name is bar",
        "msgtype": "m.text",
        "m.new_content": {
            "body": "Hello! My name is bar",
            "msgtype": "m.text"
        },
        "m.relates_to": {
            "rel_type": "m.replace",
            "event_id": "$some_event_id"
        }
    },
    // ... other fields required by events
}

With the updated mentions behavior in Matrix 1.7, this would allow the .m.rule.is_user_mention and the .m.rule.is_room_mention rules to continue matching, even for edited events, while suppressing notifications from other edits.

Some users may be depending on notifications of edits. If a user would like to revert to the old behavior they can disable the .m.rule.suppress_edits push rule.

Potential issues

Edits of invites and tombstones

The .m.rule.invite_for_me and .m.rule.tombstone rules may still cause spurious notifications if events which match those rules are edited. Both of those are state events and not subject to valid edits.

Keeping notifications up-to-date

Mobile clients currently depend on the push notifications of edited events to update the text of on-screen notifications. The proposed push rule would result in mobile clients no longer receiving these edits; but showing slightly outdated text on a notification screen. That is only a minor impact and it would be better to separate when (& why) we send pushes vs. when we generate notifications.

Suppression of notifications to a new keyword

If an event is edited and the new event (but not the original event) matches a keyword then the notification would erroneously be suppressed.

Alternatives

An alternative solution would be to add a push rule with no actions and a condition to check whether a notification was generated for the original message.

This would be placed as an override rule before the .m.rule.contains_display_name and the .m.rule.roomnotif push rules.

This would suppress duplicate notifications, while still allow for new notifications due to new mentions or keywords changing.

Security considerations

None forseen.

Future extensions

If message edits by other senders were allowed than it would be useful to know when your own message was edited, but this is not currently allowed. A future MSC to define this behavior should take into account notifying users in this situation.

Unstable prefix

The unstable prefix of .org.matrix.msc3958.suppress_edits should be used in place of .m.rule.suppress_edits.

A previous version of this MSC used .com.beeper.suppress_edits with a different condition (which should match the same events), but different rule placement.

Dependencies

N/A

---

1. A room can be configured to be notify for "all messages" by creating a room-specific push rule with an rule_id of the room ID & has actions set to "notify" , e.g.:

   {
       "rule_id" : "!abcdef:example.com",
       "default" : false,
       "enabled" : true,
       "actions" : ["notify"]
   }
   

   See the Element Web implementation. ↩︎