[Story] EX: Notifications count in the room list and on the app badge

[mxandreas]

Description

This is not a new feature but resolves historical technical discrepancies and inconsistencies.

1. Instead of the green dot, the room list will now show the number of the notifications/messages for each room. This is expected to be a better UX as well as also be consistent with Web.

2. The app badge count (iOS only) will have a more accurate count of notifications/messages (see some limitations below).

For both, the counting will now be done on the app/client side, including the necessary back pagination in the rooms. The server-provided info is not reliable (primarily due to end-to-end encryption) and will not be used in the future. The primary limitation is that the user needs to open the app for the badge count to be accurate. E.g. if a message was read on another device, then the app badge count won't decrease until the app is opened on this device.

Also, it is worth reiterating that everywhere, the number of notifications/messages is shown and not the number of rooms (in which there is at least one such notification/message). A message is considered a notification in case one of the following is true:

• It is a reply to user's message
• It mentions the user
• The room where the message is sent, has been configured to notify for all messages.

Acceptance criteria

• In case of a UTD because the sender device is not trusted, the incoming message is displayed as a notification and counts in the notification count only if the notification setting is "All messages". If not, the message does not count as a notification: no notification from NSE, no badge count increase.

Leads

• Tech: @stefanceriu
• Design: @amshakal

Time sheeting

?

Documentation

Dependencies

• None

Out of scope

• Nothing

Open questions

• None

Subtasks

Android

iOS

Rust

Other

Sign-offs

• Android
• iOS

[mxandreas]

@stefanceriu @manuroe Please double check this, a couple of things to confirm:

1. The random/large number on app badge will go away once we disable Sygnal to send incremental update on this, correct? I know the app is already correcting that today, but I understand that once Sygnal stops sending it, it should not occur in the first place.

2. I know the app badge count won't decrease if you read the message on the other device - until you open the app on this device. However, please confirm the app badge count increases without opening the app when you get a new notification/message.

[stefanceriu]

1. Yes, exactly, that should stop happening altogether
2. Yes, each push coming in will bump the notification count by exactly 1. The main app running OR background app refreshes (which run at times decided by the system) will correct any eventual inconsistencies.

[mxandreas]

Yes, each push coming in will bump the notification count by exactly 1. The main app running OR background app refreshes (which run at times decided by the system) will correct any eventual inconsistencies.

What would be the main scenarios for inconsistencies that require corrections? For example, will the count be (temporarily) wrong because when matrix-org/matrix-spec-proposals#4028 is enabled, the server sends a push for each message in the room (which then will increase the badge count), even though it actually should not be a notification - user has set the room to "keywords & mentions only" but there is no mention/keyword in these messages.

[stefanceriu]

What would be the main scenarios for inconsistencies that require corrections?

No, actually the backend pushing down all encrypted events won't be a problem as we would decrypt them beforehand to see if they actually match the push rules. Otherwise they would get dropped and no +1 created.

The most simple case of inconsistencies is push notifications themselves not being delivered through apple systems, either because of networking issues or the phone being offline/turned off etc. Another one is the one you just mentioned about messages read on a different platform.

[mxandreas]

No, actually the backend pushing down all encrypted events won't be a problem as we would decrypt them beforehand to see if they actually match the push rules. Otherwise they would get dropped and no +1 created.

Ok, that's great - then this can be done even when the app is in the background/killed?

[stefanceriu]

Yes, the NSE (Notification Service Extension) runs its own sliding sync loops to retrieve event content and decryption keys to figure out what's what.

[manuroe]

About the "In case of a UTD" acceptance criteria I just added, check the discussion in this rageshake) for more details.
This is an edge case that can happen when unsecured devices are excluded. It will not happen any more when unverified devices will no more be able to join the network.