Why is group chat such an awkward thing in XMPP?

Openfire Openfire Support
1

First of all, I’d like to preface with a grand KUDOS to the team of openfire. I did thorough research before selecting an XMPP server and openfire definitely came out on top by a long stretch. GREAT WORK TEAM!

We recently migrated from skype to our own openfire server, but find the group/conference chat to be very difficult to effectively use. It almost seems like it wants to be an IRC instead of an effective team communication tool. Is this something thats known and being worked on, or is it just the life of XMPP?

Some points to describe what I mean

  1. We use group chats in our company to keep communications between all our remote people fast and efficient. We have upwards of 20-30 group chats, many of which containing the same people, but in different configurations. Essentially there’s a group chat for every aspect of our work. Yes, we do have a project manager, and we use that as well, but it is inefficient as a quick form of communication. Configuring all these group chats in Openfire/xmpp is a nightmare. And getting all the people to actually stay connected in each one of the group chats is challenging to say the least.
  2. So once everyone figured out how to rejoin lost group chats (spark makes it easy, but we dont like spark for many other reasons, so we use other xmpp clients), and some figured out how to “autojoin” and keep it there, we still have the problem of the chat getting flooded with ridiculous “xxxx has joined the chat.” “xxxx has left the chat.” messages! This is completely unnecessary and redundant and I can’t figure out how to stop openfire from sending these messages. I presume its openfire doing it, since it seems to happen in all the xmpp clients we’ve used. (please someone tell me how to stop these messages )
  3. We have people that use xmpp clients on mobile + desktop devices. With a lot of digging I did finally end up figuring out how to get openfire to send the messages of a chat to all clients connected with priority 0 - works about halfway decent - but you lose context of the chats since your own chats do not come through to your other devices.
  4. On that note, dare you have more than one client connected to a group chat, thats when rapid “has joined / has left” messages happen as the clients fight for the right to be THE ONE in the chat. Why in the world can’t more than one client of the same user be in a group chat?
  5. Why is it so inconsistent how it displays people’s nicknames in the group chat? From the same exact chat, half the people see some awkward user@conference nickname while others see the proper nickname. Another day, its another set of results. Yes, the server is configured to allow the end users to set their nicknames.
  6. Why can’t people just be IN the group chat indefinitely, and their status simply show online/offline? Why do they always have to leave / rejoin these group chats? again, seems like an IRC mentality. An effective internal communication tool would simply allow people to be in the group chat, whether they are online or not. Maybe some people like the IRC style for their needs, and if so, then I’d highly suggest a separation of the logic, build IRC Conference Rooms and then Group Chats. Let them function differently. As it stands, it seems to be a feature somewhere lost in the middle between these two functionalities.
  7. Offline messages held on server and delivered when recipient comes online. OK - great, nice to see that this checkbox existed in openfire. However, in practice it is quite uesless. The reason being is that when the person does come online, it doesn’t show the message as pending/unread, so they have to click through all of their chats to read back on anything that might’ve been said while they were offline.
  8. Display xxx chats to new users joining the conference. OK - again, same problem. It would be actually useful if the person knew they had 20 unread chats in that group. Not to mention all the joined/leave messages spamming the chat makes it that much more ineffective.
  9. Why does the spark client display chats like its the 1990s? The modern world uses a little bit of spacing and graphics to display chats making it easier to see what chat is from who. Spark also always shows people’s usernames instead of their nicknames (natural names). Making it even more useless since we have numbered users.

I’ll stop now while I’m ahead. And certainly hope I’m not offending anyone. I appreciate that this project even exists, so please take my comments as constructivly as I intend them to be. I wouldn’t have bothered registering and writing if I didn’t appreciate so many other aspects to this project. These are just the gripe points, the issues we have faced while trying to implement this as an effective (and secure) communication tool.

I will be glad to hear if we are simply misconfigured or misusing things, if there’s anything we should be doing different to improve our experience, thats great news to me!

1 Like
2

First of all, for the most part this message should be directed to XMPP Foundation. Openfire and Spark are only obeying the standards (well, usually).

Maybe current Group Chat implementation looks like IRC, though i think it is similar to many online web chats and some other instant messengers. It was designed this way. I feel, that you want it to be Skype or iMessage way. Unless XMPP will make some drastic changes to this xep (standard definition) i don’t see this happening anytime soon. Well, this can be done on Openfire/Spark side as a non-standard side feature, but also unlikely. Especially when we have almost no active developers here. Same goes for the presence/priority issue.

A client can disable join/leave messages. At least Spark has such option:) Maybe some other clients have such option too.

Inconsistent display names in the group chat. Depends on a client and how names are stored. Usually i don’t have such problems when all names are saved via Admin Console when creating users (using Spark, Exodus at least).

Offline messages. Probably can be done on the Spark side only, but someone will have to contribute a patch.

Displaying chats. Personal preference. I like the way Spark shows messages, without any eye-candy space bloat. Of course, it won’t hurt to have an option for this, but would probably involve changing the graphic subsystem (JTattoo at this point, which provides skinning for Spark windows).

Again, Spark and Openfire need developers and patches.

3

Basically because it was the spirit of the time (~2002) when XEP-45 aka XMPP MUC (groupchat) was defined. XMPP MUCs immitate mostly IRC with a few more features. It’s not suprisingly, as this was the chat protocol that dominated that time period.

More then 10 years later we know better. First the Publish-subscribe pattern became popular, and was specified for XMPP in XEP-60. We now know that this would be an ideal candidate to implement (group)chats that can be easily synchronized between multiple JID resources (devices of a user), and where 1:1 chats are just groupchats with 2 participants.

The only open implementation I am aware of, that comes close to such a design and also provides some drafts regarding the specification, is provided by Buddycloud: http://buddycloud.github.io/buddycloud-xep/

I recommend looking at their open-source software. The project exists for a while and seems be mature for production use: buddycloud.com

4

And getting all the people to actually stay connected in each one of the group chats is challenging to say the least.

It’s the responsibility of the client to “stay” in the chat. I assume you mean autojoin on login. The client needs to create a bookmark and autojoin the room after login. (XEP-0048)

I can’t figure out how to stop openfire from sending these messages. I presume its openfire doing it, since it seems to happen in all the xmpp clients we’ve used. (please someone tell me how to stop these messages )

No, it’s a client thing. Openfire only sends to inform the client about “joins” and “leaves”. A client can decide how to display it, e.g. it could as well only display a green “online” symbol for the occupant on join.

but you lose context of the chats since your own chats do not come through to your other devices.

Why in the world can’t more than one client of the same user be in a group chat?

Both problems are probably due to a bug in Openfire. OF-103

Unfortunately it’s there since 2008 and nothing has happened since.

Why is it so inconsistent how it displays people’s nicknames in the group chat? From the same exact chat, half the people see some awkward user@conference nickname while others see the proper nickname.

I don’t know. Probably a client issue, too. XMPP/Openfire is pretty clear with that. Maybe some rooms are anonymous and don’t send the real JID. Maybe sometimes a client displays the room nickname and others try to display the “roster nickname”, if the server sent the real JID. If you think it’s an Openfire bug, please try to reproduce.

Why can’t people just be IN the group chat indefinitely, and their status simply show online/offline? Why do they always have to leave / rejoin these group chats?

This is a big issue, which I was facing, too. Our product owner wanted it to work like Skype groupchat. I thought it’s not possible for a long time, but after having a closer look at the specification, I learned it’s possible. You are looking for members-only rooms, i.e. you create a room and define a whitelist of people who are members of the room. When a member joins a room, it can retrieve the member list and can display all of them, even when offline. When a member comes online, you just update their online status on the members list, just like in Skype.

It’s definitively possible from a XMPP/Openfire perspective.

The reason being is that when the person does come online, it doesn’t show the message as pending/unread, so they have to click through all of their chats to read back on anything that might’ve been said while they were offline.

I am pretty sure Openfire includes a (XEP-203) element on not-live messages (as per XEP-0045). So, it’s again a client issue. It could simply check for that extension and display “offline” messages differently.

It would be actually useful if the person knew they had 20 unread chats in that group.

I am seeing a problem here, even with the XMPP specification. E.g. if you have a (members-only) groupchat with 3 persons and you are offline for 1 week, while the other 2 persons keep chatting, then you come back online after 1 week. If you then want to retrieve all missed messages from the last week, it’s not that easy. You would need to store the date, when you went offline and ask the XMPP server for the messages since that date (). But it’s not very comfortable. It would be better if the XMPP server just knew, which messages it already delivered to a member. But as I said, such a feature is not specified by XMPP.

I know what you want. Just like Skype does it and it does it fine, missed messages aren’t lost.

Hope I could help. I think if you want to mimic the Skype groupchat, it can be done with XMPP and Openfire. Most problems you asked for, are client problems, or because the clients are implemented that way. The only problem I am seeing is the “don’t miss messages, even when offline for 1 month”-problem.

1 Like
5

Hi @CSH

Is there any idea about how other chat application manages its group chat ??

I think we cant implement this type of group chat using XMPP IRC chat.

What is difference between MUC IRC and PubSub related group chat ??

6

FWIW, I think some newer chat/communication solutions like Slack and Hipchat have addressed some of the concerns. They are commercial products and not open source solutions however.

7

Hello Flow,

I am using smack 4.2, and I have implemented group chat using XEP-0045 but there are a lot of edge cases to handle. Could you please tell me if XEP-0060 should be used instead?

thanks!