-
Notifications
You must be signed in to change notification settings - Fork 424
MSC4392: Encrypted reactions and replies #4392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
As per matrix-org/matrix-spec-proposals#4392 Decryption is already compatible with encrypted `m.relates_to`
There was a problem hiding this comment.
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
This comment was marked as duplicate.
This comment was marked as duplicate.
| Clients SHOULD include the entire `m.relates_to` object in the encrypted payload | ||
| of all events that include it. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Rendered
Ref matrix-org/matrix-spec#660