ср, 1 апр. 2020 г. в 01:42, Jonas Schäfer <[email protected]>:
> 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 [email protected] 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 requests) 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>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
