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

Support MSC4028 (Push all encrypted events except for muted rooms) #8539

Open
giomfo opened this issue Jun 14, 2023 · 0 comments
Open

Support MSC4028 (Push all encrypted events except for muted rooms) #8539

giomfo opened this issue Jun 14, 2023 · 0 comments
Assignees
Labels
A-Mention A-Notifications T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements

Comments

@giomfo
Copy link
Member

giomfo commented Jun 14, 2023

Description

The purpose of MSC4028 is to be able to support on mobile clients the "mentions-and-keywords-only" room notification setting in encrypted rooms.

This MSC adds a new “server-default" override push rule (.m.rule.encrypted_event) in order to force the server to push all encrypted events to the registered client except for muted room. This impacts the unread notification counts sent by the server in the sync responses. Indeed these counts will not be null anymore for encrypted rooms configured in "mentions-and-keywords-only" mode.

I list here the 2 options to support this new MSC in Element-Android:

  • option A: We do the minimum, which means we don't fix/support the "mentions-and-keywords-only" room notification setting in encrypted rooms. These rooms will still be considered as "muted" locally.

    • The additional received pushes will be ignored according to the existing Element-Android implementation - no change is required to handle them.
    • About unread notification counts, the current implementation displays a badge for a room as soon as the count is not null. This is what we have to change for the encrypted rooms when they are configured in "mentions-and-keywords-only" mode -> Do not display badge on "mentions-and-keywords-only" encrypted rooms even if the received unread count is not null (They are locally muted).
  • option B: We decide to support the "mentions-and-keywords-only" room notification setting in encrypted rooms. We have then to fix the following points:

    • Restore the possibility to check locally if an encrypted event contains the user display name. This is disabled currently here. This code has to be uncommented to handle correctly the potential user mention.
    • Restore the possibility to display/select the "mentions & keywords only" notification setting for an encrypted room. Changes are located in RoomNotificationSettingsViewState.notificationStateMapped and in RoomNotificationSettingsViewState.notificationOptions functions.
    • As soon as the new rule .m.rule.encrypted_event is present and enabled in the account push rules set, the clients have to track unread notifications themselves in encrypted rooms. Indeed the unread notification counts received from the server will be increased for each encrypted event, so the client should not display directly these counts. We should then implement the algorithm described in the MSC4028 proposal here. We may decide to check only if there is or not unread notifications in the room without counting them. The client would display a dot to highlight rooms with unread notifications (instead of a badge with a count).

Are you willing to provide a PR?

Yes

@giomfo giomfo added the T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements label Jun 14, 2023
@giomfo giomfo self-assigned this Jun 14, 2023
@giomfo giomfo changed the title Implement MSC4028 - Support mentions & keywords only room notification setting Support MSC4028 (Push all encrypted events except for muted rooms) Jun 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Mention A-Notifications T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements
Projects
None yet
Development

No branches or pull requests

1 participant