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

Andrew Nenakhov andrew.nenakhov at redsolution.com
Mon Apr 6 20:42:31 UTC 2020

ср, 1 апр. 2020 г. в 01:42, Jonas Schäfer <jonas at wielicki.name>:

> This message constitutes notice of a Last Call for comments on
> XEP-0357.
> Title: Push Notifications
> Abstract:
> This specification defines a way for an XMPP servers to deliver
> information for use in push notifications to mobile and other devices.
> URL: https://xmpp.org/extensions/xep-0357.html
> This Last Call begins today and shall end at the close of business on
> 2020-04-08.
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes. Push notifications are necessary to make XMPP work on one major
computer platforms: iOS/iPadOS. To a lesser extent, it is useful on Android
and Web platforms.

2. Does the specification solve the problem stated in the introduction
> and requirements?

No, it does not. It used to, but not it is completely useless where it
matters most, on iOS.

I repeat: *current XEP-0357 is completely useless with the current policies
of Apple*.

3. Do you plan to implement this specification in your code? If not,
> why not?

We have implemented this specification in our upcoming iOS clients with
great results, using background VoIP notifications. However, Apple changed
policy on using such notifications, making them unusable for anything but
incoming voice calls. The other type of background notifications have very
low priority and are very heavily throttled, and developers are supposed to
deliver 1-2 such notifications per hour *or less*. This rules out any use
of it for any kind of real-time communications.

As a replacement, Apple provides so-called service extensions, which allow
some code execution. HOwever, it is generally not enough to establish a
full-blown XMPP stream, and access from such extensions to app data is very
limited. Also, while you *can* modify an 'alert' type message to display
actual data, you can not create a call interface of it. So to make
everything work you need to make the app server use different types of
notifications for VoIP and regular messages, and, consequently, XMPP server
has to send more verbose notifications to the app server.

My team and I have spent a better portion of last two months circumventing
all these problems, and we have an almost working prototype. Problems are
aplenty and make you rethink most of the things we generally do in XMPP. We
basically have these tasks:
 - show call interface for call, chat message for chat
 - cancel call interface if call was accepted on another device
 - clear notification about message if it was read on another device
 - correctly work with carbons
 - display incoming subscription requests (and hide accepted subscription

and you have to do all of it *WITHOUT AN XMPP CONNECTION*. This is hardly
possible without putting more meaningful payload into push notification.

In short, we changed the process for registration for push notifications,
client and xmpp server exchange a symmetric encryption key to encrypt
payload. Key is to be frequently updated.

In the payload, we pass an ID of message (for chat messages), or and ID of
a read message, or details about incoming subscription requests (BTW,
PubSub Avatars suck badly, curse those who invented them). If it is a VoIP
call, there is a flag telling the App server to use VoIP notification
channel, else it uses a regular 'alert' notification channel.

Yes, the app server is now aware if someone calls the user, not just
sending the message. It's a privacy risk we were unable to remove.

Next, the app server gets a push notification and passes the payload to the
client via an appropriate channel.

The client receives this message, decrypts it with an encryption key and
establishes a very limited xmpp connection that does just one thing:
authenticates and fetches just one message by ID from a message archive
(XEP-0313 MAM). It happens rather fast, in seconds. Then it changes the
default push notification text to text fetched from the archive. This is
done without launching an app.

Once a user interacts with a notification, an app is launched and can
establish an XMPP connection in a regular way.

This is a mostly working scheme right now on our test servers with our test
app builds. There are still some problems we didn't yet fully overcome,
like notifications are delivered to devices regardless of an app state, and
if it is already active, the notification does not have clear way to know
if the app is actually running, potentially leading to conflicting
resources and one of the connections being dropped. We have some ideas how
to circumvent this.

This is our findings from a work in progress, once we have a
production-ready working client, server and app server, we'll publish our
protocol with more details and description of covered cases.

To an extent, this technique can be used for browser clients that rely on
web push notifications, they work mostly similar. Android can use this
technique too, but on this platform it is not as vital as on iOS

Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com <http://www.redsolution.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200407/72693108/attachment-0001.html>

More information about the Standards mailing list