Explanation: message synchronization between clients

Openfire Openfire Support
1

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 client must support this.

Starting with Openfire 3.9.2 version it has support for this protocol: OF-758 Add support for XEP-0280 “Message Carbons”.

There is also 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”.

Spark has received support for this in 2.9.0 version (which is not released yet at the moment of adding this information). SPARK-1585 Add support for XEP-0280 “Message Carbons”. It needs some additional work as it is not always working as intended.

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)
  • Xabber (Android - freeware)

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 plugin 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:

Spark doesn’t have support for MAM or older XEP-0136 yet. 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 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.

1 Like
2

I think you can add Xabber, a free Android app, to the list of supported clients. It seems to work and there is a setting that sounds like the same thing, though it does not explicitly say “Message Carbons” or XEP-0280.

3

Thanks for pointing out. Just tested it, Xabber indeed supports Carbons.

4

My pleasure. Now if I could just get this functionality with my favourite Windows client, Miranda NG :wink: