[Standards] DEFERRED: XEP-0357 (Push Notifications)

Ненахов Андрей andrew.nenakhov at redsolution.ru
Tue Oct 2 16:59:17 UTC 2018


вт, 2 окт. 2018 г. в 21:28, Thilo Molitor <thilo at eightysoft.de>:
>
> This XEP needs at least a note discouraging the use of the fields "message-
> sender" and "message-body" because of privacy implications.

Indeed, we found out that best practice is to omit any personal
information in a message, no counters, messages, subscriptions. Just
content updates.
However, we do transmit account UUID in push notification, because a
client might often have more than one XMPP account, and it is a bad
idea to wake up all of them and check for content updates. By
transmitting UUID we make sure that the client knows what account
should be woken up with a content update notification.

> In the wild the field "message-body" is left empty for low priority pushes (in
> short: pushes not related to message stanzas containing a body) and set to
> something like "New Message!" for high priority pushes.
> This is at least needed for iOS apps not having VoIP permissions.

On high/low priority notifications, I think it's beyond the scope of
this XEP to select priority of notification, that should be left for
appserver implementation. Issues you cite with iOS are quite severe,
but they are strictly iOS-related and are not present in FCM or
Chinese jpush or others.

As for VoIP notifications. Xabber for iOS works rather well even with
simple content-update background notifications. Big drawbacks are that
app is unable to receive such notifications after device reboot and if
an app was swiped away. However, alert-type notifications require to
either fill in meaningless 'new message' notifications or transmit
message contents over Apple's service. Later is unacceptable and
former is very bad UX.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru


More information about the Standards mailing list