From a3cabb236024385f496457c1ddc5d7384b408e98 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:40:09 +0000 Subject: [PATCH 01/11] MSC4076: Let E2EE clients calculate app & encrypted-room badge counts themselves --- proposals/4076-e2ee-aware-badges.md | 120 ++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 proposals/4076-e2ee-aware-badges.md diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md new file mode 100644 index 00000000000..6d9818a60e6 --- /dev/null +++ b/proposals/4076-e2ee-aware-badges.md @@ -0,0 +1,120 @@ +# MSC4076: Let E2EE clients calculate app & encrypted-room badge counts themselves + +## Problem + +Some push notification implementations (e.g. APNS) let the server update the notification badge count shown on an app +directly from the server, without the client running any code[^1]. In the early days of Matrix before we landed E2EE +this was a desirable thing to do, because: 1) the server knew how many pushes it had sent to the client 2) the client +displayed all pushes 3) the client typically didn't run code on receiving push, but just relied on the OS to display +the push. + +However, since E2EE landed, this breaks down for E2EE rooms because only the client can reliably know whether a given +message should trigger a push notification or not - given only the client can see the event type and event contents +of E2EE messages, and so decide whether to notify based on the event type being visible - or based on mention keywords +within the message contents. + +The workaround since we launched E2EE has been to assume that all events in E2EE rooms are visible, and so if an E2EE +room is configured to notify for all messages, unrenderable events will still trigger a push notification and increment +the `unread_notifications` count for that room and consider that room as unread when calculating the app badge count +passed to the push gateway. As a result, invisible events like VoIP signalling will trigger an app badge count. + +Meanwhile, clients now display notifications on both Android & iOS by running local code on receiving a push, rather +than displaying it verbatim from the server. This means the push rules can be executed locally and notifications should +only be displayed if the event actually is visible and matched the push rules. Moreover, the clients can calculate and +track their own accurate `unread_notification` count for E2EE rooms (while still using the `unread_notification` count +in the /sync response for non-E2EE rooms if they want), and from that calculate an accurate app badge count +clientside. + +The problem is that the server still tries to override the app badge count whenever it sends a push to the client though, +which at best will be wrong (either understeering due to missing E2EE mentions, or oversteering due to alerting about +rooms with invisible events) - and at worst will race and fight[^2] with the app badge count maintained locally by the +app, if any. + +Therefore we need a way for sophisticated E2EE clients to tell the server to stop overriding their app badge count. + +Also, the server currently tracks which events the user has read, and will send a 'null' push to the client to update +the app badge count once a given pushed event has been read. But given the server doesn't reliably know what events +cause pushes in E2EE rooms, we will need a new mechanism to reduce the badge count as the user reads rooms (or parts +them, or reconfigures their push settings). + +Finally, a separate but related problem is that historically the description of the `unread` count passed to push +gateways in the Push API is currently wrong[^3]: it says it's "The number of unread messages a user has across all of +the rooms they are a member of." but in practice it's "The number of rooms the user has with unread push +notifications" (although synapse has a config option to change that, confusingly). So we should fix that too. + +## Solution + +When a pusher is registered for a given device via `POST /_matrix/client/v3/pushers/set`, we add a new boolean field +to the request called `e2ee_badge_aware` which defaults to `false` if absent. + +If `e2ee_badge_aware` is set to true, then the pusher will not specify `unread` or `missed_calls` in the +`POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. + +We also add a new optional field to read receipts called `cleared-notifs` which defaults to `false` if absent. This is +set to `true` by e2ee-badge-aware clients to indicate that a given receipt means the user has read all push +notifications for this room's main timeline. The server should then send a 'null' push notification to all other +clients to encourage them to sync and recalculate their app badge counts, ensuring that the app badge count decreases +when the user catches up on a given room. + +## Potential issues + +1. It's not clear that the push extension will be able to reliably calculate badge counts, as they run with very +constrained resources, and the client will need to have spidered all unread messages in all E2EE rooms to get a correct +number. So if the client has been offline for a while and comes back, we have a problem if the push service has given +up pushing the client, and potential notifs get dropped. Perhaps we can detect when this happens (e.g. seqnums on push +notifs?) and warn the user to launch the app to catch up on any notifs they may have missed? + +2. Rather than sending a null push to clients to get them to update their app badge counts, should we instead send the +`cleared-notifs` read receipt details through - to tell them which room cleared its notifs, and at which event, rather +than requiring them to /sync and guess? This seems likelier to succeed within resource constraints, but exposes more +metadata to the push provider on what events have been read by the user. This in turn could be mitigated by +[MSC3013](https://github.com/matrix-org/matrix-spec-proposals/pull/3013). + +3. Just because one client thinks a room's notifs have been cleared doesn't mean a different client will agree, so if +another client has more noisy per-device rules, it may end up with a stuck app badge count. A workaround could be for +e2ee_badge_aware clients to set `cleared-notifs: true` on every RR they send if they spot that the user has per-device +rules. Alternatively, they could set `cleared-notifs: true` whatever when the user reads the most recent message in +the room as a guaranteed point where all clients will agree that there are no unread notifs. +Given per-device rules aren't common currently in the wild, I suggest we punt this to a later MSC. + +4. Ideally we should also omit `unread_notifications` and `unread_thread_notifications` in /sync responses entirely for +E2EE rooms for that device, given they will be subtly wrong and encourage the client not to correctly calculate them +themselves. However, this is hygiene rather than functionality and can be a different MSC for an `e2ee_badge_aware` +room_filter or similar. + +## Alternatives + +We could track app badge count on the server, but let it be set your clients instead - e.g. by a dedicated API like +`POST /_matrix/client/v3/pushers/set_badge { badge: 123 }`, which would in turn push it to all clients so they are in +sync. This would avoid each client individually trying to figure out when to reduce the badge count in its Push +Extension - instead the client sending the read receipts would do it for them. But on the other hand, it would not +work with per-device push rules. (Then again, nor does the proposed solution). + +Alternatively, we could push all devices every time the user sends a read receipt anywhere, just in case they need to +recalculate their app badge count. This would have an avoidable and large impact on battery life. + +In terms of configuring pushers as e2ee_badge_aware: we could also do this via a per-device underride push rule with +a custom `action` of `e2ee_badge_aware`. However, this isn't really a push action: it shouldn't be changeable by other +push rules, for instance. Instead it's config data at the point the pusher is created, hence putting it there. + +## Security considerations + +This assumes a user can trust their other apps to accurately say when they're sending a read receipt which will clear +the badge count for a given room. This doesn't seem unreasonable. + +## Unstable prefix + +Until this MSC is merged: + * `e2ee_badge_aware` should be prefixed as `org.matrix.msc4076.e2ee_badge_aware` when setting pushers + * `cleared-notifs` should be prefixed as `org.matrix.msc4076.cleared-notifs` when sending read receipts which clear + all the notifs in the room. + +## Dependencies + +None. + +## Footnotes + +[^1] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943362 +[^2] https://github.com/vector-im/element-x-ios/issues/2066 +[^3] https://github.com/matrix-org/matrix-spec/issues/644 \ No newline at end of file From 83e681f8a74372dce7927eac441e2833f720391a Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:43:40 +0000 Subject: [PATCH 02/11] fix footnotes --- proposals/4076-e2ee-aware-badges.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 6d9818a60e6..09b99807ac4 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -115,6 +115,6 @@ None. ## Footnotes -[^1] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943362 -[^2] https://github.com/vector-im/element-x-ios/issues/2066 -[^3] https://github.com/matrix-org/matrix-spec/issues/644 \ No newline at end of file +[^1]: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943362 +[^2]: https://github.com/vector-im/element-x-ios/issues/2066 +[^3]: https://github.com/matrix-org/matrix-spec/issues/644 \ No newline at end of file From 8a35baeac52c1862236dcfc83f6a6d0002be4f42 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:51:47 +0000 Subject: [PATCH 03/11] note to fix existing spec bugs --- proposals/4076-e2ee-aware-badges.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 09b99807ac4..3d7a0f99349 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -56,6 +56,11 @@ notifications for this room's main timeline. The server should then send a 'nul clients to encourage them to sync and recalculate their app badge counts, ensuring that the app badge count decreases when the user catches up on a given room. +Finally, we fix the spec to describe the behaviour of the `unread` count field in `POST /_matrix/push/v1/notify` +correctly. We also remove the `missed_calls` field at all, as nothing has ever implemented it, as far as I know - I +think it was originally included for questionable futureproofness and never hooked up ("ooh, if we are tracking unread +message notifs, let's also track unread call notifs")[^4]. + ## Potential issues 1. It's not clear that the push extension will be able to reliably calculate badge counts, as they run with very @@ -117,4 +122,5 @@ None. [^1]: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943362 [^2]: https://github.com/vector-im/element-x-ios/issues/2066 -[^3]: https://github.com/matrix-org/matrix-spec/issues/644 \ No newline at end of file +[^3]: https://github.com/matrix-org/matrix-spec/issues/644 +[^4]: https://github.com/matrix-org/synapse/blame/bdc21e72820e148941bbecb36200d51ca340748d/synapse/push/httppusher.py \ No newline at end of file From fceab8deda5ec8d42d53140f6c187332b5da5154 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:52:58 +0000 Subject: [PATCH 04/11] s/-/_/ --- proposals/4076-e2ee-aware-badges.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 3d7a0f99349..526d6114d7e 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -50,7 +50,7 @@ to the request called `e2ee_badge_aware` which defaults to `false` if absent. If `e2ee_badge_aware` is set to true, then the pusher will not specify `unread` or `missed_calls` in the `POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. -We also add a new optional field to read receipts called `cleared-notifs` which defaults to `false` if absent. This is +We also add a new optional field to read receipts called `cleared_notifs` which defaults to `false` if absent. This is set to `true` by e2ee-badge-aware clients to indicate that a given receipt means the user has read all push notifications for this room's main timeline. The server should then send a 'null' push notification to all other clients to encourage them to sync and recalculate their app badge counts, ensuring that the app badge count decreases @@ -70,15 +70,15 @@ up pushing the client, and potential notifs get dropped. Perhaps we can detect notifs?) and warn the user to launch the app to catch up on any notifs they may have missed? 2. Rather than sending a null push to clients to get them to update their app badge counts, should we instead send the -`cleared-notifs` read receipt details through - to tell them which room cleared its notifs, and at which event, rather +`cleared_notifs` read receipt details through - to tell them which room cleared its notifs, and at which event, rather than requiring them to /sync and guess? This seems likelier to succeed within resource constraints, but exposes more metadata to the push provider on what events have been read by the user. This in turn could be mitigated by [MSC3013](https://github.com/matrix-org/matrix-spec-proposals/pull/3013). 3. Just because one client thinks a room's notifs have been cleared doesn't mean a different client will agree, so if another client has more noisy per-device rules, it may end up with a stuck app badge count. A workaround could be for -e2ee_badge_aware clients to set `cleared-notifs: true` on every RR they send if they spot that the user has per-device -rules. Alternatively, they could set `cleared-notifs: true` whatever when the user reads the most recent message in +e2ee_badge_aware clients to set `cleared_notifs: true` on every RR they send if they spot that the user has per-device +rules. Alternatively, they could set `cleared_notifs: true` whatever when the user reads the most recent message in the room as a guaranteed point where all clients will agree that there are no unread notifs. Given per-device rules aren't common currently in the wild, I suggest we punt this to a later MSC. @@ -111,7 +111,7 @@ the badge count for a given room. This doesn't seem unreasonable. Until this MSC is merged: * `e2ee_badge_aware` should be prefixed as `org.matrix.msc4076.e2ee_badge_aware` when setting pushers - * `cleared-notifs` should be prefixed as `org.matrix.msc4076.cleared-notifs` when sending read receipts which clear + * `cleared_notifs` should be prefixed as `org.matrix.msc4076.cleared_notifs` when sending read receipts which clear all the notifs in the room. ## Dependencies From 27877b5250fae4d6e02a1f13bc313765bcbc8ebf Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:54:38 +0000 Subject: [PATCH 05/11] typo --- proposals/4076-e2ee-aware-badges.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 526d6114d7e..15e1c7103de 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -89,7 +89,7 @@ room_filter or similar. ## Alternatives -We could track app badge count on the server, but let it be set your clients instead - e.g. by a dedicated API like +We could track app badge count on the server, but let it be set by your clients instead - e.g. by a dedicated API like `POST /_matrix/client/v3/pushers/set_badge { badge: 123 }`, which would in turn push it to all clients so they are in sync. This would avoid each client individually trying to figure out when to reduce the badge count in its Push Extension - instead the client sending the read receipts would do it for them. But on the other hand, it would not From aa51372d8f1bafbf0a54cd44930c8a67dd34e2b7 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 02:55:52 +0000 Subject: [PATCH 06/11] fix MSC name --- proposals/4076-e2ee-aware-badges.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 15e1c7103de..9718ccc1cef 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -1,4 +1,4 @@ -# MSC4076: Let E2EE clients calculate app & encrypted-room badge counts themselves +# MSC4076: Let E2EE clients calculate app badge counts themselves ## Problem From 9d68fb208e239543abcd8ae64637dfbdefa90abe Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Nov 2023 03:01:28 +0000 Subject: [PATCH 07/11] more pros & cons --- proposals/4076-e2ee-aware-badges.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 9718ccc1cef..9c48fc5ed6f 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -93,7 +93,8 @@ We could track app badge count on the server, but let it be set by your clients `POST /_matrix/client/v3/pushers/set_badge { badge: 123 }`, which would in turn push it to all clients so they are in sync. This would avoid each client individually trying to figure out when to reduce the badge count in its Push Extension - instead the client sending the read receipts would do it for them. But on the other hand, it would not -work with per-device push rules. (Then again, nor does the proposed solution). +work with per-device push rules. And if the local client happens to be stale on spidering for old push events, the +incorrect badge count would leak confusingly to the other clients which may be more accurate themselves. Alternatively, we could push all devices every time the user sends a read receipt anywhere, just in case they need to recalculate their app badge count. This would have an avoidable and large impact on battery life. From 7a4bbd312becc38e10de9a27dddcad005dd56681 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 29 Nov 2024 10:19:21 +0000 Subject: [PATCH 08/11] fix thinko on clear_notifs --- proposals/4076-e2ee-aware-badges.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 9c48fc5ed6f..bb814eeef94 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -50,11 +50,14 @@ to the request called `e2ee_badge_aware` which defaults to `false` if absent. If `e2ee_badge_aware` is set to true, then the pusher will not specify `unread` or `missed_calls` in the `POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. -We also add a new optional field to read receipts called `cleared_notifs` which defaults to `false` if absent. This is -set to `true` by e2ee-badge-aware clients to indicate that a given receipt means the user has read all push +We also add a new optional field to read receipts called `cleared_notifs` which defaults to `false` if absent. This +SHOULD be set to `true` by clients implementing this MSC to indicate that a given receipt means the user has read all push notifications for this room's main timeline. The server should then send a 'null' push notification to all other clients to encourage them to sync and recalculate their app badge counts, ensuring that the app badge count decreases -when the user catches up on a given room. +when the user catches up on a given room. This is needed to replace the prior behaviour where the server would be +responsible for calculating and pushing new app badge updates to clients - instead, the client has to tell the server +when to nudge clients with a blank push to get them to calculate their own badge count, otherwise they will show +a stale count. Finally, we fix the spec to describe the behaviour of the `unread` count field in `POST /_matrix/push/v1/notify` correctly. We also remove the `missed_calls` field at all, as nothing has ever implemented it, as far as I know - I @@ -124,4 +127,4 @@ None. [^1]: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification#2943362 [^2]: https://github.com/vector-im/element-x-ios/issues/2066 [^3]: https://github.com/matrix-org/matrix-spec/issues/644 -[^4]: https://github.com/matrix-org/synapse/blame/bdc21e72820e148941bbecb36200d51ca340748d/synapse/push/httppusher.py \ No newline at end of file +[^4]: https://github.com/matrix-org/synapse/blame/bdc21e72820e148941bbecb36200d51ca340748d/synapse/push/httppusher.py From 8bf28cb16dfadfc32de1a87a8c78d567edbe177f Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 29 Nov 2024 11:40:46 +0000 Subject: [PATCH 09/11] split out 'clear-notifs' into a separate MSC --- proposals/4076-e2ee-aware-badges.md | 51 ++++++++--------------------- 1 file changed, 13 insertions(+), 38 deletions(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index bb814eeef94..e256b6f67ff 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -1,4 +1,4 @@ -# MSC4076: Let E2EE clients calculate app badge counts themselves +# MSC4076: Let E2EE clients calculate app badge counts themselves (disable_badge_count) ## Problem @@ -35,7 +35,7 @@ Therefore we need a way for sophisticated E2EE clients to tell the server to sto Also, the server currently tracks which events the user has read, and will send a 'null' push to the client to update the app badge count once a given pushed event has been read. But given the server doesn't reliably know what events cause pushes in E2EE rooms, we will need a new mechanism to reduce the badge count as the user reads rooms (or parts -them, or reconfigures their push settings). +them, or reconfigures their push settings). However, this can be split into a separate MSC. Finally, a separate but related problem is that historically the description of the `unread` count passed to push gateways in the Push API is currently wrong[^3]: it says it's "The number of unread messages a user has across all of @@ -45,21 +45,15 @@ notifications" (although synapse has a config option to change that, confusingly ## Solution When a pusher is registered for a given device via `POST /_matrix/client/v3/pushers/set`, we add a new boolean field -to the request called `e2ee_badge_aware` which defaults to `false` if absent. +to the request called `disable_badge_count` which defaults to `false` if absent. -If `e2ee_badge_aware` is set to true, then the pusher will not specify `unread` or `missed_calls` in the +If `disable_badge_count` is set to true, then the pusher will not specify `unread` or `missed_calls` in the `POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. -We also add a new optional field to read receipts called `cleared_notifs` which defaults to `false` if absent. This -SHOULD be set to `true` by clients implementing this MSC to indicate that a given receipt means the user has read all push -notifications for this room's main timeline. The server should then send a 'null' push notification to all other -clients to encourage them to sync and recalculate their app badge counts, ensuring that the app badge count decreases -when the user catches up on a given room. This is needed to replace the prior behaviour where the server would be -responsible for calculating and pushing new app badge updates to clients - instead, the client has to tell the server -when to nudge clients with a blank push to get them to calculate their own badge count, otherwise they will show -a stale count. +Solving the problem of prodding other clients to update their badge counts when a user reads messages in a given room has been +split out into a separate MSC. -Finally, we fix the spec to describe the behaviour of the `unread` count field in `POST /_matrix/push/v1/notify` +While we're here, we also fix the spec to describe the behaviour of the `unread` count field in `POST /_matrix/push/v1/notify` correctly. We also remove the `missed_calls` field at all, as nothing has ever implemented it, as far as I know - I think it was originally included for questionable futureproofness and never hooked up ("ooh, if we are tracking unread message notifs, let's also track unread call notifs")[^4]. @@ -72,20 +66,7 @@ number. So if the client has been offline for a while and comes back, we have a up pushing the client, and potential notifs get dropped. Perhaps we can detect when this happens (e.g. seqnums on push notifs?) and warn the user to launch the app to catch up on any notifs they may have missed? -2. Rather than sending a null push to clients to get them to update their app badge counts, should we instead send the -`cleared_notifs` read receipt details through - to tell them which room cleared its notifs, and at which event, rather -than requiring them to /sync and guess? This seems likelier to succeed within resource constraints, but exposes more -metadata to the push provider on what events have been read by the user. This in turn could be mitigated by -[MSC3013](https://github.com/matrix-org/matrix-spec-proposals/pull/3013). - -3. Just because one client thinks a room's notifs have been cleared doesn't mean a different client will agree, so if -another client has more noisy per-device rules, it may end up with a stuck app badge count. A workaround could be for -e2ee_badge_aware clients to set `cleared_notifs: true` on every RR they send if they spot that the user has per-device -rules. Alternatively, they could set `cleared_notifs: true` whatever when the user reads the most recent message in -the room as a guaranteed point where all clients will agree that there are no unread notifs. -Given per-device rules aren't common currently in the wild, I suggest we punt this to a later MSC. - -4. Ideally we should also omit `unread_notifications` and `unread_thread_notifications` in /sync responses entirely for +2. Ideally we should also omit `unread_notifications` and `unread_thread_notifications` in /sync responses entirely for E2EE rooms for that device, given they will be subtly wrong and encourage the client not to correctly calculate them themselves. However, this is hygiene rather than functionality and can be a different MSC for an `e2ee_badge_aware` room_filter or similar. @@ -99,25 +80,19 @@ Extension - instead the client sending the read receipts would do it for them. work with per-device push rules. And if the local client happens to be stale on spidering for old push events, the incorrect badge count would leak confusingly to the other clients which may be more accurate themselves. -Alternatively, we could push all devices every time the user sends a read receipt anywhere, just in case they need to -recalculate their app badge count. This would have an avoidable and large impact on battery life. - -In terms of configuring pushers as e2ee_badge_aware: we could also do this via a per-device underride push rule with -a custom `action` of `e2ee_badge_aware`. However, this isn't really a push action: it shouldn't be changeable by other +In terms of configuring pushers as `disable_badge_count`: we could also do this via a per-device underride push rule with +a custom `action` of `disable_badge_count`. However, this isn't really a push action: it shouldn't be changeable by other push rules, for instance. Instead it's config data at the point the pusher is created, hence putting it there. ## Security considerations -This assumes a user can trust their other apps to accurately say when they're sending a read receipt which will clear -the badge count for a given room. This doesn't seem unreasonable. +None ## Unstable prefix Until this MSC is merged: - * `e2ee_badge_aware` should be prefixed as `org.matrix.msc4076.e2ee_badge_aware` when setting pushers - * `cleared_notifs` should be prefixed as `org.matrix.msc4076.cleared_notifs` when sending read receipts which clear - all the notifs in the room. - + * `disable_badge_count` should be prefixed as `org.matrix.msc4076.disable_badge_count` when setting pushers + ## Dependencies None. From af2b7ae5148a34cc375dff74161c02efcb79fadf Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 29 Nov 2024 11:56:14 +0000 Subject: [PATCH 10/11] xref MSC4234 --- proposals/4076-e2ee-aware-badges.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index e256b6f67ff..06c4f42075c 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -35,7 +35,8 @@ Therefore we need a way for sophisticated E2EE clients to tell the server to sto Also, the server currently tracks which events the user has read, and will send a 'null' push to the client to update the app badge count once a given pushed event has been read. But given the server doesn't reliably know what events cause pushes in E2EE rooms, we will need a new mechanism to reduce the badge count as the user reads rooms (or parts -them, or reconfigures their push settings). However, this can be split into a separate MSC. +them, or reconfigures their push settings). However, this can be considered as a separate MSC: +[MSC4234](https://github.com/matrix-org/matrix-spec-proposals/pull/4234) Finally, a separate but related problem is that historically the description of the `unread` count passed to push gateways in the Push API is currently wrong[^3]: it says it's "The number of unread messages a user has across all of @@ -51,7 +52,7 @@ If `disable_badge_count` is set to true, then the pusher will not specify `unrea `POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. Solving the problem of prodding other clients to update their badge counts when a user reads messages in a given room has been -split out into a separate MSC. +split out into a separate MSC: [MSC4234](https://github.com/matrix-org/matrix-spec-proposals/pull/4234). While we're here, we also fix the spec to describe the behaviour of the `unread` count field in `POST /_matrix/push/v1/notify` correctly. We also remove the `missed_calls` field at all, as nothing has ever implemented it, as far as I know - I From 1b844434774e317ce863c72eb26d170d2b9f8e47 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 29 Nov 2024 17:47:13 +0000 Subject: [PATCH 11/11] withhold the `counts` block in /notify, from manu --- proposals/4076-e2ee-aware-badges.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4076-e2ee-aware-badges.md b/proposals/4076-e2ee-aware-badges.md index 06c4f42075c..c68e9c4ed84 100644 --- a/proposals/4076-e2ee-aware-badges.md +++ b/proposals/4076-e2ee-aware-badges.md @@ -48,7 +48,7 @@ notifications" (although synapse has a config option to change that, confusingly When a pusher is registered for a given device via `POST /_matrix/client/v3/pushers/set`, we add a new boolean field to the request called `disable_badge_count` which defaults to `false` if absent. -If `disable_badge_count` is set to true, then the pusher will not specify `unread` or `missed_calls` in the +If `disable_badge_count` is set to true, then the pusher will not specify `counts` block in the `POST /_matrix/push/v1/notify` request to the target push gateway, and so not override the client's app badge. Solving the problem of prodding other clients to update their badge counts when a user reads messages in a given room has been