вт, 7 апр. 2020 г. в 12:55, Andrzej Wojcik <andrzej.woj...@tigase.net>: > This is required for iOS, as high priority notifications cannot be muted or > skipped on iOS.
They actually can, at the moment, with a bit of hacking. But I agree that this might change if Apple changes their policies again. > Which means, that Push component is required to now if notification should be > displayed or not. > It is not possible to filter them on the client side. It is definitely possible. > Clients should not be forced to fetch. Fetching is not always possible, ie. > on iOS > max timeout for fetch is up to 30s but it can be reduced to lower value by iOS > depending on usage, battery level, etc. Due to that it is not possible to be > sure > that fetch will be possible. We fetch in ~ 2-4 seconds on regular mobile/wifi connections. On very bad 2G connection fetching can take up to 10 seconds. So only *if* this somehow fails, the user is presented by a fallback alert notification with default text. I'm yet to experience it in a real world usage with our current build. > Moreover, each fetch requires establishing connection, etc. It would be far > better > to skip that and reduce energy usage. Fetching a 'heavy' payloaded push notification is essentially the same as establishing a connection and doing a quick pull from the server's archive. The upside is that you don't pass any extra information via two third-party services. > At the Summit, I've suggested to send all required data within Push > notification, > but for security reasons, encrypted by XMPP server initiating push > notification. > Here is a document which describes encryption process done by us at Tigase > https://tigase.github.io/tigase-xeps/docs/push-notifications/encrypt/ Our protocol is rather similar, but we adamantly stand to avoid sending any meaningful payload through push notification whenever possible. Also, push notifications have limits on payload size, so if you'll try to pass long messages, you'll have to somehow cut them on the server, or the notification will be dropped by APNS. Also, OTR/OMEMO encrypted messages generally exceed the push notification limit by APNS (especially when encoded in base64), which makes this method even worse. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
