when is priority "normal" and when it is "high"?

[Electrofenster]

Hey guys,

I want to know, when the priority for fcm notifications are "normal" and when they are "high". In one room, I'll get the prio "normal" so no background notification could be started because the priority are to low. In the others rooms the priority are "high". I could not figure out why the priority is normally "high" but in some cases are "normal".

The room notification settings are always "standard" on both rooms.

[DMRobertson]

For GCM/FCM, the priority is set here based on the priority of the notification request n:

https://github.com/matrix-org/sygnal/blob/d52568e248a00015e6759d354bc80205f3069709/sygnal/gcmpushkin.py#L330-L332

That field n.prio is described in the Push Gateway Spec here. I think this is going to come from the homeserver, so to fully answer your question we'd to understand how your homeserver decides if a notification is low or high priority.

Assuming your homeserver runs Synapse, its logic for choosing a priority is as follows:

https://github.com/matrix-org/synapse/blob/e0f11ae4a5688a0521f20f36e440c87cfccfd69a/synapse/push/httppusher.py#L308-L316

I would guess that you get high priority notifications in rooms that are E2E encrypted.

[Electrofenster]

well that's interesting.

The first room has E2E not enabled the second has it enabled. So the first send's randomly "normal" and "high" priorities?

So as your second link describes, I'll get high if:

• highlighted
• sound on
• e2e enabled

but how could any other android device handle the notification for an unencrypted room when the notification is "normal" and a normal message get's send?

in my unencrypted room I'll get sometimes high and sometimes normal. So maybe I'll get a notification for a normal text message and sometimes not. That make no sense for me.

[reivilibre]

In one room, I'll get the prio "normal" so no background notification could be started because the priority are to low.

Would you mind expanding on this?

I'm vaguely aware that both Android and iOS have been getting more extreme with battery saving recently.

However, traditionally I believe that low-priority notifications would be batched together and delivered at a more 'convenient' time, rather than absolutely immediately. The device still receives them.

Are you saying that low priority notifications are now causing issues?

The rules for deciding whether a message causes a highlight and/or a sound are called push rules. I think we're painfully aware that we need more flexibility in this area, but there are troublesome issues, especially around end-to-end encrypted messages.

[Electrofenster]

@reivilibre for example:

1. user1 opens the app from app drawer/homescreen
2. user1 send some messages in an unencrypted room
3. user1 closes the app (on android) from recents apps, so the app is in quite state
4. user2 sends new messages on the unencrypted room

user1 didn't get an notification because the priority is "normal" so the app can't wake up the device from quite state because the priority ist not high enough.

See: https://firebase.google.com/docs/cloud-messaging/concept-options#setting-the-priority-of-a-message -> high priority

also it could be that fcm overrides the priority with "normal" because there were no interaction with the past notifications. Is it posible to log the outgoing request to fcm to see the priority?

[reivilibre]

The link you've sent me has this to say about normal priority:

Normal priority. This is the default priority for data messages. Normal priority messages are delivered immediately when the app is in the foreground. When the device is in Doze, delivery may be delayed to conserve battery. (1) For less time-sensitive messages, such as notifications of new email (2), keeping your UI in sync, or syncing app data in the background, choose normal delivery priority.

(emphasis mine)

(1) suggests that the normal priority notifications will still be delivered, just not immediately. (it's not very specific about when, though, is it?) (2) suggests that this is a good priority for non-urgent messages (though I do sympathise that this is not a case where this fits everyone)

it could be that fcm overrides the priority with "normal" because there were no interaction with the past notifications.

I believe this is one of the reasons why we would want to avoid sending everything as high. A lot of rooms are pretty high-traffic and the notifications for those probably don't get interacted with much.

Is it posible to log the outgoing request to fcm to see the priority?

I don't think we log the priority, but I think you could add that without too much hassle.

[richvdh]

What is left to be done on this issue? It seems to be just a question which has now been answered?

[reivilibre]

I think this question has indeed been answered.