Skip to content
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

MSC3767: Time based notification filtering #3767

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
126 changes: 126 additions & 0 deletions proposals/3767-time-based-notification-filtering.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
# MSC3767: Time based notification filtering
anoadragon453 marked this conversation as resolved.
Show resolved Hide resolved
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.

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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 1-7 | An array of integers representing days of the week on which the rule should match, where 1 = Monday, 7 = Sunday | **Required** |
kerryarchibald marked this conversation as resolved.
Show resolved Hide resolved


- `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"
kerryarchibald marked this conversation as resolved.
Show resolved Hide resolved
]
}
```


## 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that an overhead that can be avoided?
Isn't it better to omit the time zone and always handle the time zone in the client? Then an unintentional security issue would not occur.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.