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

Thilo Molitor thilo at eightysoft.de
Tue Oct 2 17:15:44 UTC 2018


The appserver can not know which message has high priority and which one is low priority without the xmpp server telling it.
And for this to work the XEP has to be updated with a new field or the last-message field has to be reused for this (that's what current implementations do).

Content update notifications in iOS tend to be not quite reliable and can be throttled vor filtered completely if Apple likes to. And as you noted: after reboot vor app swipeaway they are not delivered at all.

That's why ChatSecure for android uses high and low priority pushes. That doesn't make for a super nice UX but at least it is working.

Thilo


Am 2. Oktober 2018 18:59:17 MESZ schrieb "Ненахов Андрей" <andrew.nenakhov at redsolution.ru>:
>вт, 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
>_______________________________________________
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: Standards-unsubscribe at xmpp.org
>_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181002/bdfaaf58/attachment.html>


More information about the Standards mailing list