Skip to content

Latest commit

 

History

History
100 lines (80 loc) · 6.21 KB

3890-remote-local-notification-toggle.md

File metadata and controls

100 lines (80 loc) · 6.21 KB
Raw

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)) 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

Proposal

Add a new account data event m.local_notification_settings.<device-id> with content:

{
    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, 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, 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.<device-id> account_data events for the given device, and communicate these changes to clients as described in MSC3391.

A server is to clean up deleted device account data when able to do so, such as with MSC3391: Removing account data.

Support

Clients that implement m.local_notification_settings.<device-id> 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 which can be used to define per-device push rule sets. In combination with the notify_in_app action proposed in MSC3768 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. 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 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.<device-id> should use the unstable prefix org.matrix.msc3890.local_notification_settings.<device-id>