[Standards] DEFERRED: XEP-0357 (Push Notifications)
andrew.nenakhov at redsolution.ru
Fri Oct 5 14:34:33 UTC 2018
What you suggest imposes additional logic on the XMPP server to decide
between 'important' and 'not important'. Usually, this approach leads
to less-than-satisfactory results because users requirements differ
(see Facebook's, Instagram's Twitter 'algorithmic' feeds, that really
made users happy /s). The correct approach is to deliver every push to
the device, so every push is 'important.' It's a shame that push
services don't work this way, but since we still have the means to make
notifications work as required (VoIP notifications for Apple), that's the way
to build apps, leaving push services and app servers as they currently
вт, 2 окт. 2018 г. в 23:41, Thilo Molitor <thilo at eightysoft.de>:
> > 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
> 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.
> > 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.
> > Current content-update notifications are mostly working too, at least for
> > us.
> > They are not ideal, yes, but for the future we've decided on different
> > approach to this problem. Instead of playing around Apple's restrictions
> > and filtering we plan to bite the bullet and add voice calls capability.
> > This will allow nicely working notifications with absolutely no changes to
> > appserver or XEP.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
Директор ООО "Редсолюшн" (Челябинск)
More information about the Standards