Skip to content

Conversation

@tulir
Copy link
Member

@tulir tulir commented Dec 26, 2025

@tulir tulir added e2e proposal A matrix spec change proposal kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Dec 26, 2025
tulir added a commit to mautrix/go that referenced this pull request Dec 26, 2025
As per matrix-org/matrix-spec-proposals#4392

Decryption is already compatible with encrypted `m.relates_to`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Client, ideally multiple

@krille-chan

This comment was marked as duplicate.

Comment on lines +28 to +29
Clients SHOULD include the entire `m.relates_to` object in the encrypted payload
of all events that include it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krille-chan originally said (PR threads should be used for discussion):

But this also means that every reaction triggers a push notification, which then has to be ignored on the client side, right? Any idea how we could avoid this? Especially for Apple devices, triggering push notifications which then do not result into a visible notification on the device this could lead to problems iirc and it is in general not very energy efficient if every reaction wakes up a device, decrypts a message only for the info that it can be ignored.

Maybe adding a flag to the unencrypted content, that this message does not necessary trigger a notification could be useful here? This could also then be used for future use cases like encrypted state events

Copy link
Member

@anoadragon453 anoadragon453 Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This refers to the .m.rule.suppress_edits default override rule which suppresses notifications related to event replacements:

{
    "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 proposal would result in this push rule being ineffective in encrypted rooms. A push notification would always be sent to the client for edits (using some resources), but clients running the push rules locally would then not actually pop a notification as they'd be able to see the m.relates_to field in the decrypted event source.

Battery life vs. privacy of communications has come up before during the Intentional Mentions MSC, and ultimately the SCT decided to prioritise privacy over battery life. MSC3996 is a proposal which aims to mitigate the problem somewhat by adding a boolean to the unencrypted portion that hints to the homeserver whether they should send a push or not, though that MSC has not gotten traction.

I would like to see this MSC at least mention the implications for push notifications.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a push notifications section to potential issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

e2e kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants