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

Thilo Molitor thilo at eightysoft.de
Thu Nov 1 23:37:12 UTC 2018


As I said already in another thread:

https://mail.jabber.org/pipermail/standards/2018-October/035387.html :

This XEP needs at least a note discouraging the use of the fields "message-
sender" and "message-body" because of privacy implications.

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.

The field "message-count" is ambiguous and should be removed completely or 
defined what is counted by it.
The prosody implementation hardcodes its value to "1".

The field "pending-subscription-count" is not used by prosody at all.
I don't know if other implementations use it.

The business rules proposed by Daniel should be incorporated into the XEP as 
well: https://mail.jabber.org/pipermail/standards/2016-February/030925.html

Prosody's implementation rationale for these are explained here: https://
hg.prosody.im/prosody-modules/file/tip/mod_cloud_notify/business_rules.markdown


AND https://mail.jabber.org/pipermail/standards/2018-October/035396.html :
> Appserver might take notice that app didn't wake up after three
> content-update notification and send an alert notification on fourth
> attempt. We don't do that, however.
Well, that wouldn't make for good UX at all. Push notifications are sent for 
non-body messages, too. Having an alert notification without some visible 
change when you open the app (because only "silent" xmpp stanzas triggered 
push) is bad.
And imho chatting is about real-time communication. Missing (maybe important) 
messages for several minutes or maybe for hours just because fewer than 3 
pushes were sent out is bad, too (some account with only a few contacts, 
something often seen with xmpp newcomers).
I agree that the only viable solution is to implement some VoIP capability 
short of apple changing their policy, BUT:

Having a priority for messages helps where that is not feasible (or something 
that will be implemented later after other XMPP functions have been 
implemented). And there could come other push services for which this priority 
thing will be needed, too.

The thing is: Having the capability for priorizing messages when needed in the 
XEP will reflect what ChatSecure and possibly others need and are already 
doing.
Not standardizing this despite of demand in this will ensure every app needing 
this will do some homegrown not interoperable implementation/patch.
Chatseucre demanded its users to patch prosody to support a priority field.

AND: not standardizing this will just not reflect reality. Prosody AND ejabberd 
both allow the last-message field to be used for priority signaling.
Standardizing a new field for this and removing the new-message field altogether 
would be better, privacy wise and standards wise.


Cheers,
Thilo


Am Montag, 22. Oktober 2018, 14:26:17 CET schrieb Ненахов Андрей:
> > I think that in the long term, we need to empower the server to do just
> > that. You propose that the client (or user?) should make the decision
> > what is important, by sending every push to the client. However, this is
> > bad for battery usage (you don't want your device to wake up on every
> > MUC presence change).
> 
> I don't propose that the client should make the decision what is
> important. Quite the opposite - server does. And *if* the server
> decides, that some event is important enough, it sends push and client
> wakes up. No need for additional levels of logic with different levels
> of push notifications importance, that indeed does put significant
> overheads on both clients and servers.
> 
> > What's still not solved is how to interface that with E2EE (an encrypted
> > MUC message might or might not contain your name, demaning a push).
> 
> Ah, this is simple. MUC message simply won't reach your server because
> your client is not connected to it.  Unless, of course, you use some
> crutches to patch this unfortunate broken by
> design IRC clone.
> 
> > In the short term, we should codify the rough set of guidelines in the
> > XEP, as suggested by Thilo and Daniel, and have high-priority and
> > background pushes.
> 
> If by 'high priority' pushes you mean use alert-type push
> notifications in iOS, I'm opposing the idea of using them in at all.
> It's either bad UX or privacy breach, both are bad.
> 
> 
> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (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
> _______________________________________________


More information about the Standards mailing list