Explanation: message synchronization between clients

Version 20

    Background:

     

    Some systems like Apple's Messages or Google Hangouts support syncing of incoming and outgoing messages between a few connected clients with the same username.

     

    Openfire is a XMPP standards compliant server, so mostly it has features (XEPs) provided by XMPP standard (xmpp.org). Custom features can be added, but they shouldn't interfere with the standards. So, sometimes there is no way to add something to Openfire as this would make it a non-standard server.

     

     

    Message Carbons:

     

    XMPP has a XEP covering synchronization of the outgoing and incoming messages between several clients logged in with the same username (XEP-0280: Message Carbons). This protocol is still in an experimental state, so no servers or clients are obligated to support it. Both server and a client must support this.

     

    Starting with Openfire 3.9.2 version the server has a support for this protocol: [OF-758] Add support for XEP-0280 "Message Carbons" - Jive Software Open Source

    There is also a support for this in the Smack library (starting with 3.4.0 version), which various clients are based on (e.g. Spark): [SMACK-529] Add support for XEP-0280 "Message Carbons" - Jive Software Open Source

    Spark doesn't have support for this yet. Here's a ticket for this [SPARK-1585] Add support for XEP-0280 "Message Carbons" - Jive Software Open Source Nobody is working on it as Spark currently has no active developers.

     

    Here's a list of clients that are known to support Message Carbons. Feel free to extend this list:

    • Yaxim (Android - freeware)
    • Conversations (Android - commercial)
    • Gajim (Linux, BSD, Windows - freeware) (note: in my test not always worked reliably, but this may be my testing environment's fault)

     

    Note: this only works when both (or more) clients are online. If client1 sends a message, but client2 was offline during that moment, client2 won't have this sent message in his history. There is no history synchronization like in Google Hangouts.

     

     

    Message Archiving and Message Archive Management:

     

    There are also two XEPs covering history storing on the server and history synchronization between devices. Older and more broad XEP-0136: Message Archiving and still in experimental state XEP-0313: Message Archive Management. There is no full support for this in IgniteRealtime projects (as far as i know), but Monitoring Service has some support for this, also Openfire has an initial support. Smack doesn't have MAM support yet. When implemented, this will allow to have history storage and full synchronization a'la Hangouts/iMessage style.

     

    Related tickets in the tracker:

    [OF-1113] Improve, broaden, and update support for XEP-0136 and XEP-0313 - IgniteRealtime JIRA

    [SMACK-435] Add support for XEP-0136 Archive Messaging - IgniteRealtime JIRA

    [SMACK-625] Add support for XEP-313: Message Archive Management - IgniteRealtime JIRA (Implemented in Smack 4.2.0)

    [SPARK-1728] Add support for XEP-0313 Message Archive Management - IgniteRealtime JIRA

     

    Spark doesn't have support for MAM or older XEP-0136 yet (Spark is currently using Smack 4.1.9 and updating it to 4.2.0 should be another epic task). Xabber has an option to store history on the server. Most probably it can also retrieve it from the server. Conversations (Android client) has support for MAM (XEP-0313).

     

     

    Route.all-resources setting (old partial workaround):

     

    Openfire has an option to create a system property route.all-resources and set it to value true. This setting makes Openfire send a copy of an incoming message to every connected client with the same username, different resources (in xmpp a client can only be logged with the same username simultaneously if every connection is using a different resource, e.g. user@server/resource1 and user@server/resource2) and the same highest priority. But the server sends copies of messages to a bare JID (full JID: user@server/resource; bare JID: user@server). Usually clients send replies with a full JID and XMPP standards require that server should always send a message to one resource only, if a message has been sent to a full JID. This way usually only a first message is received by all connected clients, but as one of them starts replying, then the conversation only goes through that client. In addition, there is also route.really-all-resources setting, which, when enabled, will send same message to all connected clients regardless of their priority (but it has to be a non-negative priority).

     

    These settings haven't been intended for full message synchronization and shouldn't be used for that. Message Carbons or MAM is the way to go.