|
| 1 | +# MSCXXXX: "Do not Disturb" notification settings |
| 2 | + |
| 3 | +"Do not Disturb" (DnD) is a common feature of notification settings on various chat platforms. It |
| 4 | +may act globally but also on a per-room or per-device basis and involves inhibiting prominent visual |
| 5 | +or audible notifications without stopping to track them. This makes it possible for users to consume |
| 6 | +these notifications later once DnD is disabled. It is important to differentiate DnD from "Muting" |
| 7 | +where notifications are lost entirely and cannot be picked up on later. |
| 8 | + |
| 9 | +In Matrix, notifications for new and unread content are configured via [push rules]. Push rules |
| 10 | +currently don't support DnD. Rules can either notify or not but the notification state is entangled |
| 11 | +with the unread state. This means push rules only support muting but not DnD. |
| 12 | + |
| 13 | +As evidenced in [MSC3768] extending the push rule system to support DnD isn't trivial. This |
| 14 | +proposal, therefore, takes a different approach by introducing an overlay configuration that allows |
| 15 | +controlling DnD separately from push rules. |
| 16 | + |
| 17 | +## Proposal |
| 18 | + |
| 19 | +A new global account data event `m.do_not_disturb` is introduced. Its `content` contains a single |
| 20 | +property `rooms` that is a mapping from room ID to empty object (for future extensibility). |
| 21 | + |
| 22 | +``` json5 |
| 23 | +{ |
| 24 | + "type": "m.do_not_disturb", |
| 25 | + "content": { |
| 26 | + "rooms": { |
| 27 | + "!foo:bar.baz" {}, // Don't notify about new content in this room |
| 28 | + ... |
| 29 | + } |
| 30 | + } |
| 31 | +} |
| 32 | +``` |
| 33 | + |
| 34 | +Instead of a valid room ID, `*` is also allowed and will match any room. Otherwise, globbing is not |
| 35 | +permitted. |
| 36 | + |
| 37 | +For any room matched by `m.do_not_disturb`, clients MUST suppress system-level notifications such as |
| 38 | +sounds or notification pop-ups. Clients SHOULD also render unread state and counters less |
| 39 | +prominently for matched rooms. |
| 40 | + |
| 41 | +`m.do_not_disturb` applies to all devices in a user's account. It MAY be overridden on a per-device |
| 42 | +basis using account data events of type `m.do_not_disturb.<DEVICE_ID>`. |
| 43 | + |
| 44 | +``` json5 |
| 45 | +{ |
| 46 | + "type": "m.do_not_disturb.ABCDEFG", |
| 47 | + "content": { |
| 48 | + "rooms": { |
| 49 | + "*" {}, // Don't notify at all on this device |
| 50 | + } |
| 51 | + } |
| 52 | +} |
| 53 | +``` |
| 54 | + |
| 55 | +To avoid flooding account data with per-device configurations, home servers SHOULD delete any |
| 56 | +`m.do_not_disturb.<DEVICE_ID>` event when the given device is removed. |
| 57 | + |
| 58 | +## Potential issues |
| 59 | + |
| 60 | +This proposal creates another configuration system on top of push rules thereby complicating the |
| 61 | +overall system further. |
| 62 | + |
| 63 | +For clients that depend on remote notifications, the dispatch and delivery of these notifications is |
| 64 | +not paused when in DnD mode. This might waste a certain amount of resources on both servers and |
| 65 | +clients. |
| 66 | + |
| 67 | +## Alternatives |
| 68 | + |
| 69 | +[MSC3768] integrates DnD into the existing push rule system. This significantly increases the |
| 70 | +complexity of managing push rules, however. |
| 71 | + |
| 72 | +[MSC3881] allows clients to toggle pushers on and off without unregistering them. This makes it |
| 73 | +possible to pause the delivery of remote notifications but only works on clients that use pushers |
| 74 | +such as mobile apps. Additionally, it doesn't allow pausing notifications on a per-room level. |
| 75 | + |
| 76 | +[MSC3890] is similar to this proposal but explicitly excludes clients that rely on pushers. Similar |
| 77 | +to [MSC3881], it also doesn't work on a per-room level. |
| 78 | + |
| 79 | +Clients could also use custom local settings to store DnD configurations without any changes to the |
| 80 | +specification. This would require each client to invent its own system for storage and matching, |
| 81 | +however. Additionally, custom client settings would make it impossible to centrally control DnD for |
| 82 | +all devices at once. |
| 83 | + |
| 84 | +## Security considerations |
| 85 | + |
| 86 | +None. |
| 87 | + |
| 88 | +## Unstable prefix |
| 89 | + |
| 90 | +While this MSC is not considered stable, `m.do_not_disturb` should be referred to as |
| 91 | +`dm.filament.do_not_disturb`. |
| 92 | + |
| 93 | +## Dependencies |
| 94 | + |
| 95 | +None. |
| 96 | + |
| 97 | + [push rules]: https://spec.matrix.org/v1.15/client-server-api/#push-rules |
| 98 | + [MSC3768]: https://github.com/matrix-org/matrix-spec-proposals/pull/3768 |
| 99 | + [MSC3881]: https://github.com/matrix-org/matrix-spec-proposals/pull/3881 |
| 100 | + [MSC3890]: https://github.com/matrix-org/matrix-spec-proposals/pull/3890 |
0 commit comments