Sygnal sends all pushes with high priority level, which drains the devices resource about sygnal HOT 6 CLOSED

Looks like the push API already supports setting a priority on a notification (prio field). It defaults to high, so we should check that:

1. Sygnal correctly sets the priority on FCM based on the field, and
2. Ensure that Synapse is correctly sending that, including when its set to only send the event_id to Sygnal.

from sygnal.

Sygnal appears to correctly set the priority on both APNs and FCM pushes, but the spec says that a missing prio field should be treated as high priority, and Synapse doesn't appear to ever set the prio field [1].

from sygnal.

So. Having looked into this a bit (or should I say, had @reivilibre look into it 😀), it turns out that this is a bit of a can of worms, as: both Android and iOS want/require high priority push to trigger notifications on the device and not be ignored. Ideally this means that the server can figure out which events the client will display notifications for, and which they won't. This is complicated due to client side rules, such as decrypting e2e messages and then running the standard push rules on them.

(It's also worth noting that apps shouldn't be waiting for an API call to Synapse before displaying a notification, since e.g. a /sync can take a long time to return and the OS can kill the push handling thread before it returns. I think the suggestion in the past has been to wait a few seconds and if the API hit still hasn't returned to display a generic "You've received a new message" notification, or something like that).

This leads me to the conclusion that we can't easily fix this properly without a larger reworking of the notification and push rule system. As such I'm inclined to do something a bit hacky here that simply reduces the number of high priority pushes we send out, rather than ensuring that only push that trigger notifications will be high priority. I guess the simplest proposal would be to add some cheeky logic to Synapse so that only encrypted events and those with sound/highlight tweaks get given a high priority. (Unfortunately this can't happen on Sygnal due to it not having access to the event types and such).

I would be inclined not to spec this and simply say that this is Synapse specific logic, mainly as this feels like a hack and leads to behaviour which is not really correct. Ideally we'd follow up on this issue with a proper fix that we can then spec.

from sygnal.

matrix-org/synapse#7765 should solve this as a temporary solution

from sygnal.

Should we now close this? This issue is a bit out of scope for Sygnal since it just does what it's told.

The hack we implemented is sad but realistic — anything more will need a rework of push rules (which is coming!) and perhaps broader push in general…

from sygnal.

yeah, I think we can close this.

from sygnal.