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

MSC4141: Time based notification filtering #4141

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

hanadi92
Copy link

@hanadi92 hanadi92 commented May 8, 2024

Rendered

Took on this old MSC #3767 on time based notification filtering (do not disturb) and only added a detailed spec on the day-of-week numbering schema.

p.s. I kept the commits from the original author and just added mine on top.

Signed-off-by: Hanadi @hanadi92

Kerry Archibald and others added 14 commits May 8, 2024 17:32
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
Signed-off-by: Kerry Archibald <[email protected]>
@hanadi92 hanadi92 changed the title Time based notification filtering MSC4141: Time based notification filtering May 8, 2024
@turt2live turt2live added push proposal A matrix spec change proposal client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels May 9, 2024
Copy link
Member

Choose a reason for hiding this comment

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

Implementation requirements:

  • Client exposing UI for these options
  • Server supporting these options
  • Users demonstrating that this feature works for them (lack of bug reports, significant complaints, etc)

Copy link
Author

Choose a reason for hiding this comment

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

server implementation on Synapse is already open and ready for review here element-hq/synapse#16858

@hanadi92 hanadi92 requested a review from turt2live May 30, 2024 17:52
@turt2live turt2live removed their request for review May 30, 2024 18:03
Copy link
Contributor

@sumnerevans sumnerevans left a comment

Choose a reason for hiding this comment

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

I'm generally opposed to this proposal. I think that the functionality proposed here should be left up to the operating system the client is running on as the OS is the source of truth for timezone as well as DND status.

Comment on lines +81 to +87
##### `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.
Copy link
Contributor

Choose a reason for hiding this comment

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

I rely on seeing the red dots on chats that I have been mentioned in overnight in order to figure out what I need to address every morning, so I think that this is a significant enough UX problem to require blocking this MSC on MSC3768.

be used.

## Potential issues
- If a user changes timezone their push rules will not automatically update.
Copy link
Contributor

Choose a reason for hiding this comment

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

As someone who travels often, I think that this is a major concern. At the very least, we need to add a recommendation that clients either automatically change timezone when they enter a new timezone, or prompt the user to manually change it.

But, as mentioned I think that this functionality should be implemented by the operating system the client is running on, as it has full timezone and DND state information.

Comment on lines +94 to +97
#### 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally, I think that this entire functionality should be handled by the operating system of the client. Fundamentally, the client is where the necessary information (namely DND status) resides.

I can think of many edge cases that can cause a server-driven approach as suggested in this MSC to fail:

  • Travel: as already mentioned, users will be confused when the notification rules are off by whatever timezone offset they've traveled to.
  • Overridden DND off: if you are up late (maybe pulling an all-nighter to study for a test) and want to have your notifications on all night (maybe classmates texting study tips), you would want to be able to turn of the DND and have notifications show up.

Clients should just spit notifications out and allow the operating system to hide/show them depending on whatever rules are configured on the OS level. This will ensure that we can take advantage of whatever notification management features are provided by operating systems both now and in the future.

Obviously, it is annoying to have to configure it on multiple ecosystems, but I think this MSC actually makes it worse as you would have to configure your Matrix client DND settings in addition to your OS DND settings.

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

Choose a reason for hiding this comment

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

It appears that per-device rules are going away: matrix-org/matrix-spec#1842

## 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).
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 that forcing all times to be expressed in UTC time should be listed as an alternative. Since users will not be interacting directly with the state event, I think clients should always translate the user's setting into UTC time.

- While this MSC is not considered stable `time_and_day` should be referred to as `org.matrix.msc4141.time_and_day`

## Dependencies
None.
Copy link
Contributor

Choose a reason for hiding this comment

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

As mentioned in another comment, I think MSC3768 should be a dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal push
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants