powered by Jive Software

Feature Request: Send message to all resources

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. :slight_smile:

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.

1 Like

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.


Thanks for the hint. :slight_smile:

Then it would be nice to have this on a per user setting and without respecting the priority of the resources.r

Can someone make a Feature Request in the bug tracker?

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.

have you found a way to sync all messages to all resources with openfire or any other jabber server?

I haven’t searched though. But i don’t believe standard jabber servers will have, unless it will be included into specifications (XEPs).

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 @wroot http://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.

1 Like

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.

So is there any known current developing going on based on XEP-0280 ?

Probably not. There isn’t even a Jira ticket for it.

On top of that it is still in experimental state and there are long-standing issues which are unresolved since many years (like XEP-0079 and XEP-0198)

On the other hand it seems relatively simple to implement. I might even give it a try.

1 Like

We really need this feature (carbons), it might be a deal breaker for us.I could probably put up a small bounty if someone wnated to tackle this.

Setting route.all-resources=true should help. Do I get now a small HMS Bounty? (;

That doesn’t seem to work for us. Also its only replicates replies, it doesn’t sync the whole conversation.

No bounty for you


Have a look at http://community.igniterealtime.org/message/234438#234438

wroot explained the issue with route.all-resources really GREAT why it won’t work as ‘expected’

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;

I’ve created OF-758.

Feel free to post your bounty at https://www.bountysource.com/teams/igniterealtime

I think other’s can join the bounty too and increase the ammount. And depending on the ammount, it’s something I would certainly consider.

I’ve implemented XEP-280 in Openfire’s trunk.

Maybe sombody has the opportunity to test and/or review.


1 Like