[Standards] Proposed XMPP Extension: Inbox

Thilo Molitor thilo at eightysoft.de
Thu Jan 23 22:50:32 UTC 2020


You forgot to mention one notification type which is particularly useful in 
this context: 
You can use a Notification Service Extension to modify alert type notifications 
before they are displayed to the user.
This way your notifications won't be throttled or delayed by hours and you 
don't have to send any encrypted payload inside the notification (but you can, 
of course, but key management and decryption won't be done by apple/ios but by 
your app, so you have greater freedom here).
You can fetch the content of the notification from the xmpp server mam/inbox/
whatever and replace the dummy content of the notification by the actual 
content.
By using something like "bad network connectivity, message could not be 
loaded" as the dummy/fallback content of the notification the UX would not be 
that bad either.
As far as I know Monal is using a Notification Service Extension to display the 
message content in notifications without using VoIP pushes.

Some resources on this:
https://developer.apple.com/library/archive/documentation/NetworkingInternet/
Conceptual/RemoteNotificationsPG/ModifyingNotifications.html#//apple_ref/doc/
uid/TP40008194-CH16-SW3

https://developer.apple.com/documentation/usernotifications/
unnotificationserviceextension

https://www.logisticinfotech.com/blog/ios-push-notification-with-notification-service-extension/

- tmolitor


Am Freitag, 24. Januar 2020, 01:16:46 CET schrieb Andrew Nenakhov:
> ср, 22 янв. 2020 г. в 16:44, Florian Schmaus <flo at geekplace.eu>:
> > On 21.01.20 17:28, Andrew Nenakhov wrote:
> > > Notice: this is a rather early sketch of a copy of a technology that we
> > > already use to great results and have implemented in a open-source and
> > > available XMPP server and at least two clients on different platforms
> > > (third is upcoming in a few months, too), that sync with each other
> > > swiftly and correctly.
> > 
> > Out of curiosity, could you reveal the names of those implementations?
> 
> Names won't surptise you: server implementation is Xabber Server (XMPP
> part is a rather seriously modified version of ejabberd), and client
> implementations are Xabber for Web and Xabber for iOS. The latter is
> undergoing final cleanup stages (like, supernice voice messages
> recording, layout fixing, etc), but it's XMPP part is performing quite
> well. Xabber for Android implementation is upcoming.
> 
> Of course, they are all called the same, but we still count them as
> different, because each has a different code, and exists in a vastly
> different environments and they all have wildly varying sets of
> constraints.
> 
> The protocol extension is called XEP-0CCC Client Synchronization by us.
> 
> > > Proposed specification does not address ways to work with retracted /
> > > edited messages,
> > 
> > What do you suggest? How should retracted or edited messages be handled?
> > Could you say a few words what your specification does in this regard?
> 
> Each conversation (a basic entity of the XEP) contains version number.
> Each edit/retract changes version. On reconnect, a client compares his
> version of a conversation with server one, and can fetch delta if
> versions differ. Deletes, edits all handled the same. Probably,
> reactions would be, too. Also, a client is served only those
> conversations that had updates since disconnect.
> 
> > > and does not provide info on incoming audio calls,
> > 
> > I am not sure how incoming calls are related to an inbox functionality,
> > or are we talking about pending/unanswered ongoing incoming calls?
> 
> Very related. Key problem we have encountered when implementing for
> iOS, is that fetching call offer messages from an archive is very
> unreliable: if a sender sends something after initiating a call (very
> likely to happen in clients that do not block chat when calling), it
> is buried in the archive. When an iOS device wakes, it has a very
> short time to fetch everything and respond.
> 
> So, we have devised a solution that keeps track of active incoming
> calls and swiftly pushes this info to clients on reconnect after push.
> In short, it works really well, we could not achieve that with regular
> message archive (Xabber for iOS is able to work on servers without
> support for Client Synchronization, the difference is noticeable).
> 
> > > This also
> > > affects XEP-0353 Jingle Message Initiation, which is no longer
> > > practical, even with our additional roundtrip that we proposed last
> > > summer)
> > 
> > How does this affect xep353. Do you have a pointer to your proposal
> > involving an additional roundtrip?
> 
> I've sent it in august or september in a long thread about 0353, but
> here it is again:
> https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge
> 0ow/edit
> > What are those changes to Apple APNS and which changes are required to
> > xep357 because of those?
> 
> APNS has 'alert' type notifications, that are delivered rather
> swiftly. Problem is, they are handled without even opening the app.
> So, if you want to send a message to an app, you just send a text to
> display, right through apple's servers in unencrypted plaintext.
> (Famous secure messenger Telegram did just that, for all non-secret
> messages). Once a user interacts with a notification, an app is
> launched and can connect to the server in the foreground. You can pass
> some payload with such 'alert', but this payload is inaccessible until
> the app is launched.
> 
> APNS has also 'content available' background type notifications. When
> the app receives such notification in the background, it has 30
> seconds (officially. in reality, less than 20 seconds) to connect to a
> server, fetch updates, retrieve new messages and present them to a
> user. (Not an easy feat with regular XMPP!). It is a good secure way
> to deliver data directly to an app. Problem is, this type of
> notifications has very low priority. Messages can be throttled down
> and be delayed for HOURS. Blah blah blah apple seeks to improve user
> experience and reduce battery usage. Oh, and if the app is swiped
> away.. it no longer receives such notifications AT ALL, until actively
> launched again.
> 
> Up until recently, there was a third option. APNS provided a special
> form of background notifications, with great reliability and low
> delays, but ONLY for apps that have VoIP functionality, so these apps
> can provide VoIP services that do require a rather immediate reaction.
> To have access to these good working notifications we did bite the
> bullet and add Jingle calls to an app. It worked great with our
> modified Jingle Message Initiation routine...
> 
> ... only to learn last summer that Apple bans use of such background
> notification and makes mandatory use of VoIP kit on each received
> notification. It means that every notification of this type should
> bring up the call screen, or be banned from receiving VoIP pushes.
> 
> Oh, they also added an option to encrypt payload of 'alert type'
> modifications, with a static key. In XMPP, this means This means that
> a client must provide a server with a public key (a special one that
> can be retrieved on iOS device without launching the app!), the server
> must encrypt payload with this key, pass it to push service, which
> somehow must understand, which messages are just messages, and should
> be passed as encrypted 'alert' messages, or if they are VoIP call
> initiation and must be sent as VoIP push.
> 
> This, unfortunately, makes a push server a way more active participant
> in communications between clients and servers: it now must be "clever"
> and know, which pushes are calls, and which are not. Also, this means
> that the model of XEP-0353, with our improvements or without, no
> longer makes any sense: if we get "clever" pushes, we can send
> 'propose' right in the push as well, not waiting for an app to fetch
> anything from an archive. Roundtrips are no longer necessary at all.
> 
> Even if we do not make push service "clever" we still must change how
> XEP-0357 Push Notification works, because we now need to send an
> encrypted payload to iOS clients, instead of just 'push'.
> 
> The alternative is to either send 'new message' alert messages on
> every update (horrible UX), or send very slow and unreliable
> background notifications (also horrible UX) (Btw, 5 years ago they
> worked well, but apple has made them work WAY worse).
> 
> More info about APNS changes:
> https://onesignal.com/blog/ios-13-introduces-4-breaking-changes-to-notificat
> ions/
> https://apple.slashdot.org/story/19/09/05/1644258/apple-change-causes-scram
> ble-among-private-messaging-app-makers
> https://appleinsider.com/articles/19/08/06/changes-in-ios-13-may-force-majo
> r-redesign-of-voip-apps
> 
> Signal is obviously already affected:
> https://github.com/signalapp/Signal-iOS/issues/4280
> 
> Official stance was that apps are OK to use VoIP for background pushes
> to april 2020, but since iOS 13.2 version, we see it already enforced.
> 
> 
> Maybe this issue requires a dedicated thread.
> 
> 
> --
> Andrew Nenakhov
> CEO, redsolution, OÜ
> https://redsolution.com
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


More information about the Standards mailing list