-
Notifications
You must be signed in to change notification settings - Fork 411
MSC4359: "Do not Disturb" notification settings #4359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
# MSC4359: "Do not Disturb" notification settings | ||
|
||
"Do not Disturb" (DnD) is a common feature of notification settings on various chat platforms. It | ||
may act globally but also on a per-room or per-device basis and involves inhibiting prominent visual | ||
or audible notifications without stopping to track them. This makes it possible for users to consume | ||
these notifications later once DnD is disabled. It is important to differentiate DnD from "Muting" | ||
where notifications are lost entirely and cannot be picked up on later. | ||
|
||
In Matrix, notifications for new and unread content are configured via [push rules]. Push rules | ||
currently don't support DnD. Rules can either notify or not but the notification state is entangled | ||
with the unread state. This means push rules only support muting but not DnD. | ||
|
||
As evidenced in [MSC3768] extending the push rule system to support DnD isn't trivial. This | ||
proposal, therefore, takes a different approach by introducing an overlay configuration that allows | ||
controlling DnD separately from push rules. | ||
|
||
## Proposal | ||
|
||
A new global account data event `m.do_not_disturb` is introduced. Its `content` contains a single | ||
property `rooms` that is a mapping from room ID to empty object (for future extensibility). | ||
|
||
``` json5 | ||
{ | ||
"type": "m.do_not_disturb", | ||
"content": { | ||
"rooms": { | ||
"!foo:bar.baz" {}, // Don't notify about new content in this room | ||
... | ||
} | ||
} | ||
} | ||
``` | ||
|
||
Instead of a valid room ID, `*` is also allowed and will match any room. Otherwise, globbing is not | ||
permitted. | ||
|
||
For any room matched by `m.do_not_disturb`, clients MUST suppress system-level notifications such as | ||
sounds or notification pop-ups. Clients SHOULD also render unread state and counters less | ||
prominently for matched rooms. | ||
|
||
`m.do_not_disturb` applies to all devices in a user's account. It MAY be overridden on a per-device | ||
basis using account data events of type `m.do_not_disturb.<DEVICE_ID>`. | ||
|
||
``` json5 | ||
{ | ||
"type": "m.do_not_disturb.ABCDEFG", | ||
"content": { | ||
"rooms": { | ||
"*" {}, // Don't notify at all on this device | ||
} | ||
} | ||
} | ||
``` | ||
|
||
To avoid flooding account data with per-device configurations, home servers SHOULD delete any | ||
`m.do_not_disturb.<DEVICE_ID>` event when the given device is removed. | ||
|
||
## Potential issues | ||
|
||
This proposal creates another configuration system on top of push rules thereby complicating the | ||
overall system further. | ||
|
||
For clients that depend on remote notifications, the dispatch and delivery of these notifications is | ||
not paused when in DnD mode. This might waste a certain amount of resources on both servers and | ||
clients. | ||
|
||
## Alternatives | ||
|
||
[MSC3768] integrates DnD into the existing push rule system. This significantly increases the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a cleaner way, because it won't introduce a new parallel approach. I also think it would be way easier to implement and test. At least on the client side in Trixnity and Trixnity Messenger, where I'm currently implementing notifications from scratch up. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The main issue I ran into when implementing MSC3768 is https://github.com/matrix-org/matrix-spec-proposals/pull/3768/files#r2348952758. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Left a comment there. |
||
complexity of managing push rules, however. | ||
|
||
[MSC3881] allows clients to toggle pushers on and off without unregistering them. This makes it | ||
possible to pause the delivery of remote notifications but only works on clients that use pushers | ||
such as mobile apps. Additionally, it doesn't allow pausing notifications on a per-room level. | ||
|
||
[MSC3890] is similar to this proposal but explicitly excludes clients that rely on pushers. Similar | ||
to [MSC3881], it also doesn't work on a per-room level. | ||
|
||
Clients could also use custom local settings to store DnD configurations without any changes to the | ||
specification. This would require each client to invent its own system for storage and matching, | ||
however. Additionally, custom client settings would make it impossible to centrally control DnD for | ||
all devices at once. | ||
|
||
## Security considerations | ||
|
||
None. | ||
|
||
## Unstable prefix | ||
|
||
While this MSC is not considered stable, `m.do_not_disturb` should be referred to as | ||
`dm.filament.do_not_disturb`. | ||
|
||
## Dependencies | ||
|
||
None. | ||
|
||
[push rules]: https://spec.matrix.org/v1.15/client-server-api/#push-rules | ||
[MSC3768]: https://github.com/matrix-org/matrix-spec-proposals/pull/3768 | ||
[MSC3881]: https://github.com/matrix-org/matrix-spec-proposals/pull/3881 | ||
[MSC3890]: https://github.com/matrix-org/matrix-spec-proposals/pull/3890 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements:
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ruma (account-wide setting): ruma/ruma#2221
Rust SDK (account-wide setting): matrix-org/matrix-rust-sdk#5687