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

Conversation

kerryarchibald
Copy link

@kerryarchibald kerryarchibald commented Apr 7, 2022

Introduces time based notification filtering, enabling 'do not disturb'

Rendered

Signed-off-by: Kerry Archibald <kerrya@element.io>
@kerryarchibald kerryarchibald marked this pull request as draft April 7, 2022 10:29
Signed-off-by: Kerry Archibald <kerrya@element.io>
@kerryarchibald kerryarchibald changed the title MSC3677: Time based notification filtering MSC3767: Time based notification filtering Apr 7, 2022
Kerry Archibald added 3 commits April 7, 2022 12:34
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
@turt2live turt2live added push proposal A matrix spec change proposal 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 Apr 7, 2022
Kerry Archibald added 3 commits April 7, 2022 18:29
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
@kerryarchibald kerryarchibald marked this pull request as ready for review April 7, 2022 16:36
Kerry Archibald added 2 commits April 8, 2022 10:49
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
Kerry Archibald added 3 commits April 11, 2022 10:39
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
Signed-off-by: Kerry Archibald <kerrya@element.io>
Comment on lines +123 to +126
## 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.

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.

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

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.

| 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** |
Copy link

Choose a reason for hiding this comment

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

0 = Sunday, 1 = Monday, 7 = Sunday

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.

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

The 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).
What would be the best way to alter the MSC? Can this even be done without @kerryarchibald?

Choose a reason for hiding this comment

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

  • Many systems allow for, or assume, the counting of the days of the week from 0, representing Sunday. crontab allows this by permitting 0-7 to be used for the day of the week, with Sunday being represented by 0 or 7. date allows for it in output formatting, where %u presents the numeric day of the week starting at 1 for Monday and %w presents it starting at 0 for Sunday. Thus, challenges for implementation are likely already encountered and solved.
  • Appendix B of RFC3339 suggests in the reference implementation of ISO8601 that <value> % 7 is an appropriate mechanism for calculating numeric day of the week. In that case, 0 for Sunday is appropriate.
  • While most countries count the days of the week from Monday, some (like mine, Ireland) legally count the days of the week from Sunday. A scale (0-7, with 0,7 = Sunday) caters for this less common, but no less valid, counting scheme.

Thus, I recommend that the specification be retained as I recommended it, and as it currently is.

Copy link

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Can this even be done without @kerryarchibald?

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.

Copy link
Member

Choose a reason for hiding this comment

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

I agree. 👍

While most countries count the days of the week from Monday, some (like mine, Ireland) legally count the days of the week from Sunday. A scale (0-7, with 0,7 = Sunday) caters for this less common, but no less valid, counting scheme.

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.

Choose a reason for hiding this comment

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

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.

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:

  • Appendix B of RFC3339, which suggests in a reference implementation of ISO8601 that <value> % 7 is an appropriate mechanism for calculating numeric day of the week. In that case, 0 for Sunday is appropriate.
  • The GNU date format code %w encodes the day of the week in numeric format where 0 => Sunday (alternatively, using %u encodes the day of the week where 7 => Sunday).
  • The GNU cron day-of-the-week specification allows for 0 and 7 both to represent Sunday.

My original proposal is to allow for Sunday to be represented by either 0 or 7, which not an uncommon approach, and while I appreciate the concerns raised in response to it, I don't believe they're so severe as to warrant not facilitating it. However, it's a proposal, nothing more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.