Disclaimer: i'm not a developer, but as this question pops quite often and i have to dig for the recent conversation to provide a link or repeat everything again, i thought this could be useful to have such document and bookmark it for future references.
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 as it is using the older Smack version and even if Smack is updated to 3.4.0 it still would probably need additional work to make it work in Spark. 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 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
Spark doesn't have support for MAM or older XEP-0136. As it still relies on the older Smack version, it won't have support for this even when Smack implements it. Spark needs a competent developer to update it to the latest Smack. Xabber has an option to store history on the server. Most probably it can also retrieve it from the server.
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 a same username, different resources (in xmpp a client can only be logged with a 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.
This setting hasn't been intended for full message synchronization and shouldn't be used for that. Message Carbons or MAM is the way to go.