diff --git a/proposals/3890-remote-local-notification-toggle.md b/proposals/3890-remote-local-notification-toggle.md new file mode 100644 index 00000000000..e4e620fb603 --- /dev/null +++ b/proposals/3890-remote-local-notification-toggle.md @@ -0,0 +1,100 @@ +# MSC3890: Remotely silence local notifications +Some clients (eg Element Web) do not use http pushers for notifications, but rather generate their own notifications in +the client based on the `/sync` response. Users should be able to remotely toggle on and off these notifications (as +well as [push notifications (MSC3881)](https://github.com/matrix-org/matrix-spec-proposals/pull/3881)) to control +interruptions and reachability in private and professional contexts. + +To allow these clients to silence notifications remotely we will use account data and client-side notification +filtering. + +This proposal seeks to silence interrupting notifications that are generated in the client. This includes: +- system notifications such as system banners, popups, system notification center +- sounds, including noisy notifications and ringers + +In-app notifications will not be affected, with in-app notification center, badges, unread markers and counts remaining +the same. + +*This proposal only refers to notifications that are generated on the client. Silencing of push notifications is covered +by [MSC3881: Remotely toggle push notifications](https://github.com/matrix-org/matrix-spec-proposals/pull/3881)* + +## Proposal +Add a new account data event `m.local_notification_settings.` with content: +```jsonp +{ + is_silenced: boolean +} +``` + +##### During client-side notification generation: + +- While a registered pusher exists for the current device any `local_notification_settings` event should be ignored and + events should trigger system notifications as normal. For servers that support + [MSC3381](https://github.com/matrix-org/matrix-doc/pull/3881), the `local_notification_settings` is ignored and local + notifications are triggered based on the `enabled` setting of the registered pusher. +- While no `local_notification_settings` event exists for the current device, or a `local_notification_settings` event + exists where `is_silenced` is falsy, events should be processed as normal and trigger system notifications and sounds + where necessary. +- While a `local_notification_settings` event exists for the current device where `is_silenced` is true, no event should + trigger a system notification or sound. + +##### Displaying notification settings: + +Clients should endeavour to display notification settings that reflect the rules above. + +- While a registered pusher exists for a device, notifications should be displayed as enabled. While the client has the + ability to register/remove pushers for the device, toggling this setting should register or remove the pusher. For + servers that support [MSC3381](https://github.com/matrix-org/matrix-doc/pull/3881), notifications should be displayed + as enabled according to the `enabled` setting of the pusher. Changing this setting should update the `enabled` + field of the pusher. +- While the client does not have the ability to register a pusher and a `local_notification_settings` event exists, + notifications should be displayed as `enabled` when the event's `is_silenced` field is falsy. Updating the setting + should change the event's `is_silenced` field. +- While the client does not have the ability to register a pusher and no `local_notification_settings` event exists, + notifications should be displayed as disabled. The setting should not be editable. + +##### During server-side removal of devices: + +- When devices are removed servers should delete any `m.local_notification_settings.` account_data events for +the given device, and communicate these changes to clients as described in +[MSC3391](https://github.com/matrix-org/matrix-spec-proposals/pull/3391). + +A server is to clean up deleted device account data when able to do so, such as with [MSC3391: Removing account +data.](https://github.com/matrix-org/matrix-spec-proposals/pull/3391) + +#### Support +Clients that implement `m.local_notification_settings.` notification filtering should ensure a +`local_notification_settings` event exists for the active device to indicate support for that device. Clients should +only expose local notification silencing controls for devices that have indicated their support. + +## Alternatives + +#### Per device account data +To enable easier retrieval and management of device-scoped account data events a new per-device account data could be +introduced. This would behave similarly to per-room account data. Per-device account data events would be removed by the +server during device removal. +With per-device account data, the event type could be +simplified to `m.local_notification_settings` + +#### Push rules with profile tags (aka per device push rules) +The spec allows for pushers to be assigned a +[`profile_tag`](https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3pushersset) which can be used to +define per-device push rule sets. In combination with the `notify_in_app` action proposed in +[MSC3768](https://github.com/matrix-org/matrix-spec-proposals/pull/3768) this would allow to toggle a pusher between the +`global` push rule set and a push rule set where all rules with `notify` actions were overridden to use `notify_in_app`. +Furthermore, the overrides could be simplified through cascading profile tags as proposed in +[MSC3837](https://github.com/matrix-org/matrix-spec-proposals/pull/3837). Keeping the two sets in sync would, however, +not be trivial. Additionally, profile tags are only partially spec'ed and there is active interest in +[removing](https://github.com/matrix-org/matrix-spec/issues/637) them entirely. If feasible, this would allow for remote +control of notifications for clients using http-pushers and local notification generation. + +Effective per device notification silencing using profile tags relies on a few complex pieces of work (push rules with +profile tags, `notify_in_app` push rule action, potentially cascading profile tags). While a more elegant solution, it +is unlikely to land in the short or medium term. This MSC proposes a short term fix for a common user issue. As +better solutions become available clients may choose to stop supporting `local_notification_settings`. + +## Security considerations +N/A + +## Unstable prefix +While this MSC is not included in the spec `m.local_notification_settings.` should use the unstable prefix +`org.matrix.msc3890.local_notification_settings.`