ср, 22 янв. 2020 г. в 16:44, Florian Schmaus <[email protected]>: > > 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
