You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I create this issue in order to list and check the potential impacts of this MSC on the current web client.
When the new push rule .m.rule.encrypted_event will be present and enabled in the account push rules set, the web client may be impacted by the 2 following changes:
The unread notification counts sent by the server in the sync responses will increase more frequently. Indeed these counts are increased for each push. For example the counts will not be null anymore for encrypted rooms configured in "mentions-and-keywords-only" mode.
The existing endpoint GET /_matrix/client/v3/notifications will return more encrypted events than it used to. Indeed all of the encrypted events will match with the new push rule (except for muted rooms).
The text was updated successfully, but these errors were encountered:
The unread notification counts sent by the server in the sync responses will increase more frequently. Indeed these counts are increased for each push. For example the counts will not be null anymore for encrypted rooms configured in "mentions-and-keywords-only" mode.
This will be fine, js-sdk already treats the notification counts on encrypted rooms as a maximal bound rather than the actual value, decreasing as it applies push rules locally
The existing endpoint GET /_matrix/client/v3/notifications will return more encrypted events than it used to. Indeed all of the encrypted events will match with the new push rule (except for muted rooms).
According to my tests applied on the existing Element-Web client, no change is required on the web client before introducing the new push rule described in MSC4028.
Indeed the current web client will not be impacted by the 2 changes mentioned in the description:
The web client seems completely ignore the notification counts for encrypted rooms from the sync. It computes its own counts. This code confirms this assumption, but this may be double checked by the web dev team.
The endpoint GET /_matrix/client/v3/notifications is currently used to fill the notification left panel with the request parameter only=highlight. This parameter prevents the web-client from receiving for the moment the additional encrypted events because the new push rule doesn't have the highlight tweak set.
The next step for this issue is to decide/plan which kind of changes based on this MSC4028 we want for the web client.
I would suggest these 2 options:
option 1: Adjust the local computation of the unread notification counts by taking into account the suggested algorithm (mainly about the gap handling, see point 4), when the rule .m.rule.encrypted_event is present and enabled in the account push rules set
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.I create this issue in order to list and check the potential impacts of this MSC on the current web client.
When the new push rule
.m.rule.encrypted_event
will be present and enabled in the account push rules set, the web client may be impacted by the 2 following changes:GET /_matrix/client/v3/notifications
will return more encrypted events than it used to. Indeed all of the encrypted events will match with the new push rule (except for muted rooms).The text was updated successfully, but these errors were encountered: