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?
It is enabled per session (i.e. connection/resource) as described in XEP-280 (with an IQ-set).
Whenever a client sends a message, a carbon copy of the message is delivered to each other carbon-enabled resource of that user (with extension).
When a message is sent to a bare JID, the message is forked to each carbon-enabled resource of the recipient, no matter of their priority.
When a message is sent to a full JID, the message is forwarded to each other carbon-enabled resource of the recipient (with extension).
You can also send “private” messages. Those won’t be forked / forwarded.
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.
Yes, you need a client with XEP-280 support. (Sorry, I don’t know of any).
You have to first enable support on that client or rather for the current XMPP session.
Thank you for the fast reply. And that sucks
Is there an open request to have this functionality added to Spark? If not am I able to open one?
Looks like Jitsi nightlies, and conversations (android) claim XEP-280 support
Here you go SPARK-1585 Though that won’t help much until someone steps up and provide a patch.
CSH, a client claiming to support XEP-280 (Conversations, android) claims that " Message Carbons is not enabled on the server"
Just to verify, there are no options that need to be enabled, new ports that need to be opened?
Server support is determined via Service Discovery (XEP-0030).
I’ve just rechecked Openfire’s SD result:
As you can see, it contains the “urn:xmpp:carbons:2” feature.
Given that XEP-280 is still in experimental state, I assume your client maybe uses an outdated XEP-280 version, i.e. checks for an old namespace (urn:xmpp:carbons:0 or urn:xmpp:carbons:1)?
Or maybe you just have to enable it for your client session and your client just displays the message, because you did not enable it?
Can we make a bounty for someone to work on developing Spark more? I still haven’t found a client that handles business chat as well as Spark, but it needs the following fixes urgently:
- Fixes to the XML history code.
A. My users randomly lose history all over the place (this happens all the time)
B. Corrupt history XML files cause Spark to hang when trying to message a user that has a corrupt history file on your local machine (this happens all the time)
- Support for message Carbons (for gmail-like multi-resource behavior)
Instead of fixing issue 1. support for server-side chat history would be amazing, so that you could access your history from any location without having to depend on local files. (for gmail-like archive access)
Integrated video chat support
Integrated whiteboard support
I’m afraid bounty alone won’t help. There is just no traction with Spark among developers. There are hopes that moving to Git for source repository will sparkle a bit of interest. Not much so far (Openfire is seeing some more attention, but it was always a more active project).
For the xml corruption part i suggest using the latest 2.7.0 builds. After a 1.5 year of using it in production i didn’t saw any history issue so far http://bamboo.igniterealtime.org/artifact/SPARK-INSTALL4J/shared/build-665/Insta ll4j/spark_2_7_0_665.exe
is probably easily doable, especially when Smack already supports it (SMACK-529), but someone has to step up. First, Spark should be adjusted for the newer Smack version. There were too many updates that can brake things.
seeing how things are with the voice chat and how complex all the Jitsi video bridge looks i somehow doubt it is doable in the near future.
There was a plugin for Spark. It has some quirks and it is not something outstanding, but it works Attaching it. Just rename to whiteboard and put into plugins folder in Spark. Then launch Spark and open chat with another user having this plugin. You will see two (should be one) additional buttons. It was produced by http://www.version2software.com/ maybe they can even share the source so it could be improved.
whiteboard 0.0.6.jar (430054 Bytes)
Why hasn’t 2.7.0 been released officially? Is the install straightforward?
Yeah, just install on top of 2.6.3. Well, i haven’t done this for a long time. If anything, you can just uninstall and do a clean install (leaving the profile in place). It won’t fix the already corrupted history files though, but at least i don’t see corruptions in new profiles.
Why… because there is currently no maintainer\lead developer for Spark. It is pretty stable and has some new features and fixes comparing to 2.6.3. But there is also some issues like voice chat (patch is in the work, but not sure how long it will take for cstux to complete it), it should probably also be upgraded to the newest Smack before official release, but that needs lots of work and testing. If you ask me, i would release it in the current state
I’ve actually implemented it as a patch for the past few Openfire versions, and I’ve been running such patched server. It made XMPP surprisingly… usable.
(the 3.9.3 one does not work as desired 100% of the time, but the first one - against 3.9.1 and below - worked great)
I don’t know how to implement it properly (as a plugin), so @CSH - your effort would be very welcome.
This is Abhinav.
I am trying to have 1 openfire user have logged in to spark im client running on different machines.
I have set the system property route.all-resources and set it to true in Openfire as you have suggested but as soon as i log in the second machine with user say X, the user X is logged out from the other client running on different machine.
I have restarted the openfire server after setting the property but the issue remains.
Please let me know what I am missing.
I am using openfire server 3.10.2 (on ubuntu Machine) and spark 2.7.3(running in windows machine).
I have found this stackoverflow link xmpp - Support multiple login at the same time in OpenFire server - Stack Overflow
which says “To send messages addressed to a bare JID in openfire to all related full JIDs (resources + bare JID), you need to set the system property
route.all-resources with the value
true in Openfire (Admin Console > Server Manager > System Properties). You will have to create this system property. Also you would have to set the same priority in both clients.”
How do i set the property for spark client.
Any help, suggestion or advise is well appreciated.
First of all, you should read this doc: Explanation: message synchronization between clients
Your other client gets logged off because of using same Resource in both clients. If it were new installations of Spark 2.7.3, then both of them will have “Spark” as a resource (default value, you can check this on the Sessions page in Admin Console). In XMPP two clients with the same JID can’t be logged at the same time with the same Resource. So in one of them go to login screen, then to Advanced menu and change Resource value to say “Spark1”. Then both clients will be able to login at the same time.
Thanks for the quick response.
I changed the resource and now both user can be logged in to different client with same JID.
However only one of them is getting the message. the other is not getting the message.
Read the document. Route.all-resources is not the solution, this is just a partial workaround in some scenarios. You need a client supporting Message Carbons. Spark doesn’t have support for that.
Sorry for the late reply from my side.
Thanks for the clarification.
I really appreciate it.