MSC4392: Encrypted reactions and replies

[tulir]

Rendered

Ref matrix-org/matrix-spec#660

[turt2live]

Implementation requirements:

• Client, ideally multiple

[anoadragon453]

@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

[anoadragon453]

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.

[tulir]

Added a push notifications section to potential issues

[krille-chan]

@tulir thank you so much. I very like the "m.priority": "low" field. What do you think about make it even be used for mention only rooms with "m.priority": "high" which does the same as "m.has_mentions": true from MSC3996 with the intention that maybe other events as mentions could also make it a priority high or other things like edits could also become priority low, if we ever want to encrypt them as well