-
Notifications
You must be signed in to change notification settings - Fork 410
MSC3767: Time based notification filtering #3767
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
285f315
1348ad1
ca714a4
f5ce11f
a4ff31a
40f6faf
1dff420
6a4aca3
dd00ad4
80d46d2
1131e67
b30e3ba
92560a7
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,133 @@ | ||
# MSC3767: Time based notification filtering | ||
Do not disturb / focus features are becoming standard across operating systems and networking products. Users expect to | ||
be able to manage the level of noisiness from an application based on day and time. | ||
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. This RFC is linked as supposedly solving the "temporarily mute channel" feature request. Unless for business users maybe, most of the time people want to simply ad-hoc temporarily mute channels for X time units, and not configure some complex time-of-day based rules. How does this RFC help implementing the former? 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 it doesn't. That would probably require a separate MSC. The purpose here was to allow setting up pre-defined DND schedules. |
||
|
||
Users should be able to configure many periods of notification levels during the day; for example before work, lunch | ||
hour, and after work. They should also be able to schedule notification levels for a particular day of the week; for | ||
example a quieter notification setting all day on No Meeting Wednesday, or complete silence over the weekend. | ||
|
||
## Proposal | ||
|
||
We introduce a push notification [condition](https://spec.matrix.org/v1.2/client-server-api/#push-rules) `time_and_day` | ||
to filter based on time of day and day of week. | ||
|
||
**`time_and_day` condition definition** | ||
|
||
| key | type | value | description | Required | | ||
| ---- | ----| ----- | ----------- | -------- | | ||
| `kind` | string | 'dnd_time_of_day' | | **Required** | | ||
| `timezone` | string | user's [Olson formatted timezone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) | The timezone to use for time comparison. This format allows for automatic DST handling | Optional. Defaults to UTC | | ||
| `intervals` | array | array of time matching intervals (see below) | Intervals representing time periods in which the rule should match. Evaluated with an OR condition | **Required** | | ||
|
||
**Time matching interval definition** | ||
|
||
| key | type | value | description | Required | | ||
| ---- | ----| ----- | ----------- | -------- | | ||
| `time_of_day` | string[] | tuple of `hh:mm` time | Tuple representing start and end of a time interval in which the rule should match. Times are [ISO 8601 formatted times](https://en.wikipedia.org/wiki/ISO_8601#:~:text=As%20of%20ISO%208601%2D1,minute%20between%2000%20and%2059.). Times are inclusive | Optional. When omitted all times are matched. | | ||
| `day_of_week` | number[] | array of integers 0-7 | An array of integers representing days of the week on which the rule should match, where 0 = Sunday, 1 = Monday, 7 = Sunday | **Required** | | ||
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 don't think this is a good idea. It's causing predictable problems in implementations and I don't see any good reason to have multiple redundant ways of representing the same data here. 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 wouldn't call it problems. I was just trying to find a neat solution for it :) I think it's a valid point from the MSC to specify that. Since there are many different implementations of weekday and ISO weekday in datetime libs. 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 MSC definitely has to specify it, but giving two different representations to the same day seems like the worst possible solution. Pick one of {0 to 6, 1 to 7}{starts on Sunday, starts on Monday}, doesn't really matter which it is, and stick with it. 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 it makes sense to be strict on the spec, whether we use 0-6 or 1-7. I'd propose to stick with ISO8601(1-7). 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. As the person who made the original suggestion, I think I might re-present the case for it:
Thus, I recommend that the specification be retained as I recommended it, and as it currently is. 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. Those issues are all easily solved using a direct mapping from one representation to another. Allowing multiple values for the same data introduces a whole class of new issues while not really solving the other ones (what if my system counts days from 0 to 6, starting on monday?). 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 haven't really read the MSC so consider this a flyby comment, but experience shows that allowing multiple representations for the same thing invariably does more harm than good. People tend to ship code that "works" rather than reading every word of a specification, so you'll end up with some implementations that only work with 0, and others that only work with 7, and a terrible mess. Make a decision and stick to it. Hard 👎 from me on the multiple representations.
If Kerry is no longer interested in pursuing this MSC, it would need someone else to volunteer to take it forward. In practice, that would probably mean creating an MSC. If you're interested in taking it over, I'd suggest making yourself known in the Office of the SCT room and we'll figure out what to do. 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 agree. 👍
This sounds like a localization issue, not a problem that needs to be solved at the protocol level. However, I'd be inclined to link out to other RFCs, etc. that define formats instead of creating our own. If this is using ISO 8601 then it make sense to be internally consistent. 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 don't believe ISO 8601 specifically references it, but as we have to pay to get permission to consult the current version, I'm not in a position to confirm. The closest I have found are the following:
My original proposal is to allow for Sunday to be represented by either |
||
|
||
|
||
- `time_of_day` condition is met when the server's timezone-adjusted time is between the values of the tuple, or when no | ||
`time_of_day` is set on the interval. Values are inclusive. | ||
- `day_of_week` condition is met when the server's timezone-adjusted day is included in the array. | ||
|
||
When both `time_of_day` and `day_of_week` conditions are met for an interval in the `intervals` array the rule evaluates | ||
to true. | ||
|
||
```json5 | ||
{ | ||
"kind": "time_and_day", | ||
"timezone": "Europe/Berlin", | ||
"intervals": [ | ||
{ | ||
"time_of_day": ["00:00", "09:00"], | ||
"day_of_week": [1, 2, 3, 4, 5] // Monday - Fri | ||
}, | ||
{ | ||
"time_of_day": ["17:00", "23:59"], | ||
"day_of_week": [1, 2, 3, 4, 5] // Monday - Fri | ||
}, | ||
{ | ||
// no time_of_day, all day is matched | ||
"day_of_week": [6, 7] // Weekend | ||
} | ||
}, | ||
``` | ||
|
||
A primary usecase for this condition is creating 'do not disturb' behaviour. | ||
For example, Wednesday morning focus time rule: | ||
```json5 | ||
{ | ||
"rule_id": ".m.rule.master", | ||
"default": true, | ||
"enabled": true, | ||
"conditions": [ | ||
"kind": "time_and_day", | ||
"timezone": "Europe/Berlin", | ||
"intervals": [ | ||
{ | ||
"time_of_day": ["09:00", "11:00"], | ||
"day_of_week": [3] // Wednesday | ||
}, | ||
], | ||
"actions": [ | ||
"dont_notify" // See note below | ||
] | ||
} | ||
``` | ||
|
||
##### `dont_notify` and Do Not Disturb behaviour | ||
`dont_notify` will stop badges from being | ||
updated in the client during 'do not disturb' hours, so the user will not be | ||
able to locate messages that were silenced when they are back online. | ||
To silence push notifications but allow discovery of missed messages in app, `notify_in_app` as proposed in | ||
[MSC3768](https://github.com/matrix-org/matrix-spec-proposals/pull/3768) should | ||
be used. | ||
|
||
## Potential issues | ||
- If a user changes timezone their push rules will not automatically update. | ||
|
||
## Alternatives | ||
|
||
#### System | ||
Some systems (e.g. iOS) have their own DND / focus mode but this is only an option if all of your devices are within | ||
that vendor ecosystem (here Apple) and doesn't help when you have e.g. an iPad and an Android phone. This also needs to | ||
be configured per device. | ||
|
||
#### `room_member_count` style comparison | ||
```json5 | ||
"conditions": [ | ||
{ | ||
"kind": "time_of_day", | ||
"is": ">=18000000" // 17:00 NZST, 5:00 UTC | ||
}, | ||
{ | ||
"kind": "time_of_day", | ||
"is": "<=75600000" // 9:00 NZST, 21:00 UTC | ||
}, | ||
|
||
] | ||
``` | ||
As only one rule per `kind` + `rule_id` is allowed and rule conditions are an `AND` this allows only one contiguous | ||
range to be defined. This precludes one of the main usecases for the feature - ignoring notifications outside of | ||
work/waking hours. | ||
|
||
#### Device assessment | ||
An alternative version of the `time_and_day` defined above used timezone agnostic times and did not define a timezone. | ||
This rule would be assessed only on the device. This is not easily achieved on every platform. | ||
|
||
#### ms offsets for time intervals | ||
Previous proposals used ms offsets to represent time of day instead of `hh:mm`. Ms offsets may behave incorrectly on | ||
days with a DST jump and are less intuitive. | ||
|
||
## Security considerations | ||
- Stores user's timezone on the server. DND periods saved to the server without timezone information would reveal | ||
information about a user's approximate timezone anyway. Users who do not wish to store their timezone can set DND | ||
periods in UTC (this option should be available in clients implementing time based notification filtering). | ||
Comment on lines
+123
to
+126
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. Isn't that an overhead that can be avoided? 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. Not all platforms are able to filter notifications locally. On iOS, for instance, you need to explicitly request a special entitlement from Apple which not all iOS clients might be willing or able to do. Also, in many cases the security issue occurs anyway regardless of whether you apply the time zone on the client or the server. As soon as you set it up to reflect your work hours, for instance, it'll be possible to infer your approximate time zone. |
||
|
||
## Unstable prefix | ||
|
||
- While this MSC is not considered stable `time_and_day` should be referred to as `org.matrix.msc3767.time_and_day` | ||
|
||
## Dependencies | ||
None. |
Uh oh!
There was an error while loading. Please reload this page.