Using gtalk with my Android phone and the Openfire gtalk plugin for a few months now, I am pretty impressed by the way gtalk forwards all messages to all resources. Its simply and easy: Start an converstation on the phone and switch over to the desktop. All messages are there.
Itâs sad that this feature isnât implemented in Openfire and itâs even sadder that there is no issue for this feature request yet (at least I found none). Please devs, create one and let the community vote.
It would be nice to see this feature as a per user setting. Which could be changed via a remote server command.
Actually it is there. You have to add a system property route.all-resources and set it to true in Openfire (then it is better to restart a server i think). But it will send same message only to resources with the same and the highest priority. Also it only sends same message to all resources if the message was send to bare JID and wasnât send to some specific resource.
Some discussion about that feature in the bug tracker: OF-29
It is not a per user feature. But every user can âconfigureâ it by setting different priorities in his clients. Just set the priority higher and only this client will receive messages, then lower the priority and every client with the same priority will get the same messages.
Will this setting also forward the outgoing messages to my other resources, like gTalk does? It looks like it does only route all incoming messages to all resources, not the outgoing. For example, if I send a message from my gtalk account with my jabber client, it will also show up in gtalk on my android phone (but not the other way around).
This setting only covers the incoming messages. Wonder if any other jabber server is doing such âsyncingâ of both incoming and outgoing messages (or history), except for the Google. They are doing not common jabber features.
XEP-0280 Message Carbons (https://xmpp.org/extensions/xep-0280.html) delivers copies of sent messages to all user resources. Though, the support of message carbons should be available on the server and the userâs client should also support this extension. I havenât seen such a plugin for OpenFire that supports message carbons on the list of available plugins.
Please note that you still have to take care of all incoming messages being delivered to all the connected resources. Have a look at this nice post by @wroothttp://community.igniterealtime.org/message/234438#234438 . Itâs a little trickier than it seems.
There is XEP-0136 Message Archiving (https://xmpp.org/extensions/xep-0136.html). Itâs supported by Openfire. Though, you still need its support on the userâs client. And not many clients support it. I know there is a plugin for Pidgin (I havenât tested it personally) and Gajim supports it. Iâve had experience of trying it out using Gajim and ejabberd as a server. It worked.
There are many pros and cons in terms of which one to use. XEP-0136 is the ultimate solution as it provides an ability to âloadâ past messages on other devices later but requires the server to keep all the conversations. XEP-0280 works without saving messages on the server but it doesnât let you to âloadâ past conversations. It works only when all resources are online at the same time.
Message carbons directly addresses the use case being discussed, which Google seems to do by default (without regard to that spec). Openfire can certainly look at implementing it, but it is not likely to satisfy the needs of many people who have asked for this feature until more clients actually implement it.
The spec requires compliance on both the server and client, but it is unlikely that any clients in broad use today currently support this spec as it has not even reached draft status yet.
The other option would be to create a proprietary server side behaviour to simply broadcast messages to all connected users with the same bare JID. I think it would be best to implement this options as a plugin, so it is not in the base code where it would make things more confusing when the Message Carbons spec is supported.
Yes, I agree that message carbons is the right way to implement it as a separate plugin. Though, rcollier is correct that it should be supported by the server as well as the client. At the moment there are not so many clients that support it.
As for the option of broadcasting all incoming messages to all connections sharing same bare JID, I think it should be implemented as a plugin (better than a patch and a server true/false option). But it should be pointed out that itâs a âpatchâ and not the behaviour by specification.
Speaking of the plugin to broadcast messages (not XEP-0280 Message Carbons) it should be noted that it can be used for incoming messages only but not to distribute own outgoing messagse to all your devices. As for the later I think the client should support message carbons as not all of them will process plain messages correctly even if the servers sends a message to the client. It will have a different âfromâ field from the full JID that particular resource has (it will be his own JID but with a different resource).
Iâm willing to implement this patch to deliver messages to all user resources no matter whether the message was sent to bare or full JID. Though, I donât have experience creating plugins for Openfire. If you can think of a way to implement it, please advise me. Iâll share the code with the community if I manage to do it the right way (plugin not a patch). Iâm pretty sure it will be a pretty popular feature based on all the requests and questions regarding it here.
First of all i like to give my +1, like and vote for implementing XEP-0280 in openfire. Native code or as a supported plugin - you decide. More and more other xmpp server software support this feature like prosody (http://prosody.im/doc/xeplist).
So is there any known current developing going on based on XEP-0280 ?
I guess the best option would be to fully implement XEP-0280 Message Carbons. Though, as an intermediate solution itâs an option to develop a plugin to forward incoming messages to all registered resources no matter whether the message is sent to a bare of full JID.
Any suggestions? Is such a temprorary plugin needed before XEP-0280 is developed? BTW, I think it could be useful in many situations when clients do not support XEP-0280. But it violates the XMPP specification on how to deliver messages.
Ooops. One could try to modify org.jivesoftware.openfire.spi.RoutingTableImpl.java:
private boolean routeToLocalDomain(JID jid, Packet packet, boolean fromServer) {
// TODO check logic and test things !!1!
if (JiveGlobals.getBooleanProperty("route.to-bare-jid", false)) {
jid = new JID(jid.toBareJID()); // legal as jid is not final .... or better create a local "jid2"? any side effects to pubsub?
}
// end of TODO
boolean routed = false;
...
