From 1c33d23feda0208574ac77194ad03e0de1b048b2 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Fri, 8 Apr 2022 20:40:36 +0200 Subject: [PATCH 1/4] Add in-app notification action proposal --- proposals/3768-notify-in-app.md | 96 +++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 proposals/3768-notify-in-app.md diff --git a/proposals/3768-notify-in-app.md b/proposals/3768-notify-in-app.md new file mode 100644 index 00000000000..79bd3e818f7 --- /dev/null +++ b/proposals/3768-notify-in-app.md @@ -0,0 +1,96 @@ +# MSC3768: Push rule action for in-app notifications + +The [push rule] system is used in two different ways. Home servers +evaluate the rules on messages (which may be encrypted) and send *push* +notifications. Clients re-evaluate the rules locally on (decrypted) +messages and display *in-app* notifications -- most commonly in the form +of notification-count badges. + +However, there is currently no way to stop sending push notifications +while still receiving in-app notifications. This is a critical feature +of "Do Not Disturb" modes where users want to stop being notified +*outside* their client but still see notifications *inside* their client +so that they can catch up on them after leaving "Do Not Disturb" mode. + +The present proposal attempts to resolve this situation by introducing a +dedicated push rule action for in-app notifications without accompanying +push notifications. + +## Proposal + +A new push rule action `notify_in_app` is introduced. + +- `notify_in_app` -- This causes each matching event to generate a + notification **without sending a push**. In particular, this means, + like `notify`, the server should consider the event when computing + `notification_count` and `highlight_count` in the `/sync` response. + Unlike `notify`, the server should not forward the notification to + any of its pushers. Clients should display in-app notifications just + like for `notify`. + +The existing `notify` action is changed to imply `notify_in_app`. + +- `notify` -- This causes each matching event to generate a + notification. Implies `notify_in_app`. + +No change to the existing default push rules is required. Servers can +treat `notifify_in_app` exactly like `notify`, merely omitting the push, +while clients don't have to distinguish between the two actions at all. +This makes for a minimally invasive solution to the problem of +in-app-only notifications. + +## Potential issues + +None. + +## Alternatives + +Several attempts at fixing similar problems have been made in the past. +Most of these alternatives fell through because they separated unread +and notification counts. For the specific case of in-app-only +notifications, such a separation is not needed and only adds unnecessary +complexity. + +For the sake of completeness, what follows is the result of an exercise +in archaeology: + +### `dont_push` action + +An experimental [Synapse PR] defined a `dont_push` action. While the +latter exhibits the same semantics as `notify_in_app`, its naming +disguises the fact that notifications are still being displayed in-app. +The PR was abandoned in favor of [MSC2625]. + +### MSC2625:`mark_unread` action / `unread_count` field + +[MSC2625] went a step further by introducing a `mark_unread` action +together with an explicit `unread_count` next to the existing +`notification_count` and `highlight_count` in the `/sync` response. As +explained above, this kind of separation is not actually needed for +in-app-only notifications. [MSC2625], too, got abandoned, this time in +favor of [MSC2654]. + +### MSC2654: Unread counts + +Finally, [MSC2654] went yet further and introduced a separate system for +computing unread counters without push rules. Again, the complexity +resulting from this separation is not actually required to support +in-app-only notifications. + +## Security considerations + +None. + +## Unstable prefix + +While this MSC is not considered stable, `notify_in_app` should be +referred to as `org.matrix.msc3768.notify_in_app`. + +## Dependencies + +None. + + [push rule]: https://spec.matrix.org/v1.2/client-server-api/#push-rules + [Synapse PR]: https://github.com/matrix-org/synapse/pull/6061 + [MSC2625]: https://github.com/matrix-org/matrix-spec-proposals/pull/2625 + [MSC2654]: https://github.com/matrix-org/matrix-spec-proposals/pull/2654 From cc735f039f04b36757f93a4a538ef1f418c52b94 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Fri, 8 Apr 2022 20:43:13 +0200 Subject: [PATCH 2/4] Remove code formatting from headings to increase legibility --- proposals/3768-notify-in-app.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3768-notify-in-app.md b/proposals/3768-notify-in-app.md index 79bd3e818f7..69853cab809 100644 --- a/proposals/3768-notify-in-app.md +++ b/proposals/3768-notify-in-app.md @@ -54,14 +54,14 @@ complexity. For the sake of completeness, what follows is the result of an exercise in archaeology: -### `dont_push` action +### dont_push action An experimental [Synapse PR] defined a `dont_push` action. While the latter exhibits the same semantics as `notify_in_app`, its naming disguises the fact that notifications are still being displayed in-app. The PR was abandoned in favor of [MSC2625]. -### MSC2625:`mark_unread` action / `unread_count` field +### MSC2625:mark_unread action / unread_count field [MSC2625] went a step further by introducing a `mark_unread` action together with an explicit `unread_count` next to the existing From fe4080099363c8ab76ef59236c2bd5f75be21f7a Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Fri, 8 Apr 2022 20:45:29 +0200 Subject: [PATCH 3/4] Update proposals/3768-notify-in-app.md Co-authored-by: Patrick Cloke --- proposals/3768-notify-in-app.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3768-notify-in-app.md b/proposals/3768-notify-in-app.md index 69853cab809..f5550441f8e 100644 --- a/proposals/3768-notify-in-app.md +++ b/proposals/3768-notify-in-app.md @@ -34,7 +34,7 @@ The existing `notify` action is changed to imply `notify_in_app`. notification. Implies `notify_in_app`. No change to the existing default push rules is required. Servers can -treat `notifify_in_app` exactly like `notify`, merely omitting the push, +treat `notify_in_app` exactly like `notify`, merely omitting the push, while clients don't have to distinguish between the two actions at all. This makes for a minimally invasive solution to the problem of in-app-only notifications. From d413236622cda90194804f7f6a156c0bda3ac748 Mon Sep 17 00:00:00 2001 From: Benjamin Bouvier Date: Mon, 18 Aug 2025 11:49:04 +0200 Subject: [PATCH 4/4] Apply suggestions from code review Co-authored-by: Johannes Marbach --- proposals/3768-notify-in-app.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/proposals/3768-notify-in-app.md b/proposals/3768-notify-in-app.md index f5550441f8e..bce6bf90fd6 100644 --- a/proposals/3768-notify-in-app.md +++ b/proposals/3768-notify-in-app.md @@ -22,11 +22,14 @@ A new push rule action `notify_in_app` is introduced. - `notify_in_app` -- This causes each matching event to generate a notification **without sending a push**. In particular, this means, - like `notify`, the server should consider the event when computing + like `notify`, the server MUST consider the event when computing `notification_count` and `highlight_count` in the `/sync` response. - Unlike `notify`, the server should not forward the notification to - any of its pushers. Clients should display in-app notifications just - like for `notify`. + Unlike `notify`, the server MAY skip forwarding the notification to + any of its pushers. Suppressing the push is OPTIONAL because clients + need to locally reapply push rules upon receiving push notifications + anyway due to E2EE. Clients MUST suppress push notifications that + resulted from `notify_in_app` but SHOULD display in-app notifications + just like for `notify`. The existing `notify` action is changed to imply `notify_in_app`. @@ -45,6 +48,9 @@ None. ## Alternatives +[MSC3881] and [MSC3890] solve a similar problem but can only disable +notifications globally and not per-room. + Several attempts at fixing similar problems have been made in the past. Most of these alternatives fell through because they separated unread and notification counts. For the specific case of in-app-only @@ -61,7 +67,7 @@ latter exhibits the same semantics as `notify_in_app`, its naming disguises the fact that notifications are still being displayed in-app. The PR was abandoned in favor of [MSC2625]. -### MSC2625:mark_unread action / unread_count field +### MSC2625: Add `mark_unread` push rule action #2625 [MSC2625] went a step further by introducing a `mark_unread` action together with an explicit `unread_count` next to the existing @@ -94,3 +100,5 @@ None. [Synapse PR]: https://github.com/matrix-org/synapse/pull/6061 [MSC2625]: https://github.com/matrix-org/matrix-spec-proposals/pull/2625 [MSC2654]: https://github.com/matrix-org/matrix-spec-proposals/pull/2654 + [MSC3881]: https://github.com/matrix-org/matrix-spec-proposals/pull/3881 + [MSC3890]: https://github.com/matrix-org/matrix-spec-proposals/pull/3890