I upgraded from Openfire 3.9.1 to 3.9.3 - in hopes of using XEP-0280.
On my desktop:
I started with Pidgin - no luck.
I loaded Gajim - no luck.
I loaded Jitsi - no luck
On my phone:
I have Conversations
I’m not sure what I’m missing with this. It looked straight forward and is supported with everything I’m testing/using.
Any ideas, or points in the right direction - would be greatly appreciated.
Thank you,
Luke
That depends what you are expecting. Personally i have tested this with Yaxim android client and it worked against Openfire. Message Carbons feature means that if you send a message in one client, another client (which supports Message Carbons) logged with the same user will get a copy of that sent message in its history.
so if user 1 has:
phone running Conversations
desktop running Gajim
user 2 has:
desktop running Jitsi
When user 2 sends a message to user 1, it should show on the desktop and the phone. It only shows on the last active location.
When you say “in its history” are you talking about the chat window? That’s what I am expecting to see.
Did you enable Message Carbons in these clients (Conversations and Gajim)?
No. Carbons are only doing this:
User 1 sends a message to user 2 in Conversations. This same message is showing as sent in Gajim also (in its history, in the chat window).
You probably want to sync received messages also (or only), but there is currently no working solution. There is a system property route.all-resources , but it only works when sending messages to bare JID and most clients use full JID to send subsequent messages (Re: [3.8.2] route.all-resources doesn’t work? ).
Unless someone creates a plugin or something modifying the route.all behavior nothing can be done to sync incoming messages to all connected resources.
Can we make a bounty for this?
No. Carbons are only doing this:
User 1 sends a message to user 2 in Conversations. This same message is showing as sent in Gajim also (in its history, in the chat window).
It also works the other way round:
User 2 sends a message from Jitsi to User 1 (bare Jid). If both resources (Gajim and Conversations) have XEP-280 enabled they both receive the message.
If user 2 instead sends to a full Jid, let’s say to Conversations, Gajim would receive an “” copy of it.
Given that both resources have XEP-280 enabled.
It seems i was mislead by this Nik’s reply (https://igniterealtime.jiveon.com/message/235680#235680 ) which inclined that Carbons will work only for the sent messages. So i have only tested this one way. Now i gave it a try again with Yaxim (on android) and Jitsi 2.5.5305 nightly build (desktop) logged with the same user (on igniterealtime.org Openfire server, which is 3.10.0 alpha i believe) and the Spark on another side with another user. Works both ways indeed. Yaxim and Jitsi received both outgoing and incoming messages. I didn’t have to enable anything. That’s great. So we don’t need to do anything about the route.all. Just need clients to support that
Of course, Google is storing history on the server, so you receive the same conversation even if one resource was offline. That’s probably the part about Message Archiving integration in the mix that Nik was talking about. But then you would have to store messages on the server and with large userbase it could take lots of space.
Daniel Castellanos wrote:
Can we make a bounty for this?
No need for bounties on this one. Unless you want to reward CSH post factum
A bounty to make Spark support it! And fix history 
Can we get a feature request for openfire for message archiving on the server? Terrabyte drives are so cheap these days, it should not be a real big issue of cost unless the company is massive.
Also, just in case, options for archive limits based on age and/or archive size would be nice as well. For example, automatically prune any chat history older than 1 year, or prune any user with a chat history larger than 1 GB, whichever comes first.
There is already Monitoring Service for this (and audit logs for basic archiving). If you mean with an option for a client to pull that history from the server, then i think latest version of that plugin supports/include Open Archive. I haven’t tried it though. Of course, one needs a client supporting that also. But in this case history will be stored in the main database, so the database will grow and this is not just a storage question then, also the performance and backup window questions (try to backup that terrabyte of data ). It doesn’t have options for pruning though. I think if anything should be done, is that this plugin should be updates/extended, rather than creating completely new one or incorporating this into Openfire’s core.
All the more reason then to keep message archives in a separate database. See my feature request in Openfire Dev forum.