[Standards] LAST CALL: XEP-0357 (Push Notifications)

Andrew Nenakhov andrew.nenakhov at redsolution.com
Tue Apr 7 11:17:21 UTC 2020

вт, 7 апр. 2020 г. в 12:55, Andrzej Wojcik <andrzej.wojcik at tigase.net>:
> This is required for iOS, as high priority notifications cannot be muted or skipped on iOS.

They actually can, at the moment, with a bit of hacking. But I agree
that this might change if Apple changes their policies again.

> Which means, that Push component is required to now if notification should be displayed or not.
> It is not possible to filter them on the client side.

It is definitely possible.

> Clients should not be forced to fetch. Fetching is not always possible, ie. on iOS
> max timeout for fetch is up to 30s but it can be reduced to lower value by iOS
> depending on usage, battery level, etc. Due to that it is not possible to be sure
> that fetch will be possible.

We fetch in ~ 2-4 seconds on regular mobile/wifi connections. On very
bad 2G connection fetching can take up to 10 seconds.

So only *if* this somehow fails, the user is presented by a fallback
alert notification with default text. I'm yet to experience it in a
real world usage with our current build.

> Moreover, each fetch requires establishing connection, etc. It would be far better
> to skip that and reduce energy usage.

Fetching a 'heavy' payloaded push notification is essentially the same
as establishing a connection and doing a quick pull from the server's
archive. The upside is that you don't pass any extra information via
two third-party services.

> At the Summit, I've suggested to send all required data within Push notification,
> but for security reasons, encrypted by XMPP server initiating push notification.
> Here is a document which describes encryption process done by us at Tigase
> https://tigase.github.io/tigase-xeps/docs/push-notifications/encrypt/

Our protocol is rather similar, but we adamantly stand to avoid
sending any meaningful payload through push notification whenever
possible. Also, push notifications have limits on payload size, so if
you'll try to pass long messages, you'll have to somehow cut them on
the server, or the notification will be dropped by APNS. Also,
OTR/OMEMO encrypted messages generally exceed the push notification
limit by APNS (especially when encoded in base64), which makes this
method even worse.

Andrew Nenakhov
CEO, redsolution, OÜ

More information about the Standards mailing list