[Standards] Proposed XMPP Extension: Inbox

Andrew Nenakhov andrew.nenakhov at redsolution.com
Thu Jan 23 20:16:46 UTC 2020


ср, 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-eEUepgRrge0ow/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-notifications/
https://apple.slashdot.org/story/19/09/05/1644258/apple-change-causes-scramble-among-private-messaging-app-makers
https://appleinsider.com/articles/19/08/06/changes-in-ios-13-may-force-major-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


More information about the Standards mailing list