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;
...
To test this we have to know a client which supports that. So, this should deliver all sent messages to all connected resources? How it is enabled on the server, or should it work automatically?
Thank you for taking the time to add this functionality. However after installing 3.9.2 and signing in on two machines, I’m not receiving messages on both instances. (one spark, one pidgin)
Would you mind providing some information that is human readable to non xmpp experts? When I pull up the XEP-280 draft/document on xmpp.org it says the following and provides some XML
When a client wants to participate in the Carbons protocol, it enables the protocol by sending an IQ-set containing a child element qualified by the namespace “urn:xmpp:carbons:2”:
this is clearly not helpful to the average user. If a client modification, or a specific client is required, it would be nice to have this information available.