Spark 2.7 - Disable "is doing something else" etc

We have recently upgraded our clients to Spark 2.7, running 3.9.3 Openfire as the chat server.

With 2.7 we’ve noticed the chat client outputting “Phil has left the conversation” when you close a window, “Phil is paying attention” and “Phil is doing something else” when you have or lose window focus. We want to disable those things - the “left the conversation” is kind of spammy to the chat window, and the “doing something else” sends the connotation that your message isn’t important enough for the recipient to respond to.

What’s the trick to disabling those messages? They didn’t exist in the older versions of Spark, and I’m not sure if it’s a Spark setting or an Openfire setting. Thanks!

I believe this was introduced here [SPARK-891] Typing notifications would be easier to see if also displayed near typing area - Jive Software Open Source

And there is no option to control that. I have filed a ticket for this, but as Spark has no active developers currently, can’t say when this will be addressed.

[SPARK-1616] Add an option to disable typing notifications (XEP-0085) in the chat window - Jive Software Open Source

It persists without using Spark - I’m on Adium on a Mac and a Spark user on the PC can see when I’ve closed the window, when I’m “paying attention”, or I’ve taken focus off the window. That’s why I’m now wondering if it’s something in Openfire that I can block.

I think it’s just Adium doing the same thing (sending typing notifications). It’s just Spark prior to 2.6.3 haven’t supported this properly, that’s why you didn’t see it with Adium before. This XEP is a standard which clients should/must follow ( ).

Reading it i see that there must be an option for a user to disable it. So Spark’s implementation is not complete. I’ve found only one reference to a server’s control"

Servers in constrained network environments (e.g., serving small-footprint clients via Jabber HTTP Polling (XEP-0025) [10] or BOSH (XEP-0124) [11]) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to XEP-0022, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.

But i haven’t heard about Openfire supporting this. I think there is probably no option to control it on the server. I have filed a ticket for Openfire also, as it is a more active project and it can have it implemented sooner than Spark, but no guarantees.

[OF-914] Add an option to suppress Chat State Notifications - Jive Software Open Source

Thanks, I appreciate the tickets being filed. Just to be clear, when you mention “Chat State Notifications” that should also include the other messages I’m seeing, such as: “User has left the conversation” and “User is paying attention” and “User is doing something else”. There may be other notifications that I haven’t seen yet.

It makes sense that we’ve never seen this under the old Spark as we have been using that for years now. In a few weeks, we are upgrading Openfire to the latest version, and we found out in the lab that the new version doesn’t play nice with SSL with older versions of Spark. The latest Spark works fine with the latest Openfire, so we’ve been upgrading clients before the server upgrade and thus have noticed these Chat State Notifications for the first time.

Yes, it should cover all these messages. There are 5 states: , , , , . Spark has its own wording for every, but technically it sends and receives those 5 packets with an associated text.

Before you upgrade to Openfire 3.10.0 make sure to check this 100% CPU Usage

You can also test 3.10.1 RC (which hopefully has a fix for this problem) or wait for 3.10.1 final.

Ignite Realtime: Beta Downloads

Thank you for the heads up - I’ll wait until 3.10.1 before I upgrade. You’ve been extremely helpful and I’ll keep an eye on [OF-914] to see if it get implemented. Thanks again!

Edit: Weird that this forum highlighted the entire line above as a link to OF-914, and I can’t seem to find a way in the post editor to remove it.

It’s a bug with Jira links integration and it was reported to Jive Software (developer of these forums) long time ago. Still waiting for a fix.

Anyway. Looks like Spark option could be sooner. Scott Clary has just commented that he will start working on this.