babolivier
commented
2 years ago One reasonable way to go forward is to make the
apns-push-typepart of the Sygnal configuration and have it set differently per appId/topic.
After a quick look it seems like this would be pretty straightforward to implement. aioapns supports passing through a value for the push type header (as of https://github.com/Fatal1ty/aioapns/commit/162c790bf1bd32c0525d36710195c047890e0022, released in v1.9), so it would just be a matter of adding a new configuration field and passing it through to the APNs request.
We were recently granted the com.apple.developer.usernotifications.filtering entitlement which allows push notifications to be completely discarded once received on the device. This is useful for hiding notifications from encrypted events we don't care about like poll answers (as opposed to showing an empty notification).
One caveat is that it only works for alert apns-push-type notifications which is an optional field we're not currently setting.
Based of https://github.com/matrix-org/sygnal/pull/305 we realized that setting that on all notifications would most likely break the voip ones as if the header doesn't match the topic "APNs may return an error, delay the delivery of the notification, or drop it altogether."
When a call invite "alert" notification comes in the iOS app makes a request to Sygnal to send a "voip" notification which in turn shows the full screen incoming call. This is done by sending a different appId in the request payload that matches one of the .voip configurations.
One reasonable way to go forward is to make the
apns-push-typepart of the Sygnal configuration and have it set differently per appId/topic.