Can openfire support superuser provisioning?


I am looking to build an application that allow supervisor/admin to able to monitor a registered group of users chatting to anonymous clients. Does openfire support this model where I can allow supervisor users to jump in to middle of a established conversation at anytime if needed?


Zemian Deng


Openfire (server) and Smack (client library) both have support for multi-user chat, which I think you could use as a basis for your application. If you create a client application using Smack, you can allow users to create chat rooms. When a room is created you can optionally provide lists of users that are allowed to join. These lists can include users, admins, moderators, and owners for example. So your application could always include certain users in the list of attendees for each room it creates. Then, at any time a moderator can join that room.

One problem is that moderators will only be able to see the chat room messages if they have joined the room. One way to handle that is to have your moderators join each room and hide them from the other users until they actually want to participate. This relies on the fact that all the users would need to use your custom application. Another option is to create an Openfire plugin to catch all messages as they pass through the server and forward them to your custom application and then allow moderators to join a room only when needed.

Here is the official MultiUserChat Specification and the relevant Smack Documentation


Thanks for the info Chris. Please allow me to dig deeper into the question.

How heavy is it, resource and performance wise, for a chat room conn vs just a user-to-user conn? My business model will likely to have supervisor user to join conversation only 20% of the time max. So majority of the time is just plain 1-to-1 chat. Will a chat room still a best solution in this case? Is there custom connection type that we can create 1-to-1 chat first, then if needed convert it to multi-chat later?

I would think a chat room allocates more resources, but I really don’t know for sure what the load difference would be. Openfire is known to scale to something like 10,000 users just using a single server machine and can go even higher with clustering.

Unfortunately, single-user chat and multi-user chat are very different animals in XMPP and therefore are completely different APIs in Smack. So if you wanted to let users start with a single user chat, you would have to develop client code that dynamically creates a multi-user chat room from a single-user chat and forces everyone to join it.

Now as I said previously, if the users start with a single-user chat, then there is no way for a moderator to monitor all those messages unless you either create an Openfire plugin to catch them all, or I suppose if there are only a couple known moderators you could have your client manually send each message to the intended user as well as each moderator user. So I think the ideas I can come up with are as follows:

1.) Chat Rooms Only: Reasonably clean to implement and does not need single chat support developed, many features available with chat rooms, wasted overhead when doing a 1-to-1 chat.

2.) Openfire Plugin: I have created a plugin in the past that logged all messages and that is pretty easy to do (about 150 lines of code) and you could then just forward them to moderators. Pretty easy to implement, performance would be good, requires server and client code, client code would have to handle the switching between single and multi-user chat though.

3.) Manual Forwarding: Send copies of each message to the moderators from the client would be only a few lines of code, assuming you had a way for the client to figure out who the moderators are. This option would be quick and simple to implement since you wouldn’t need an Openfire plugin, but would not be as efficient since it would be sending many more messages through the server. You would still need to handle the conversion between single and multi-user chat.

Oh, one additional idea that you could possibly use to handle the switch to more than 2 users. Each XMPP packet can have custom data added to it very easily, so you could maybe use all single user chat messages. When a moderator wants to join a conversation, they could send a message with a special tag that told the receiver which conversation it went with. Then, you would just add the moderator’s message to the matching single user chat window UI of the receiver. That would allow you to avoid the extra overhead and complication of developing multi-user chat room support.

So I would pick an option based on how much time you have to develop and how many users you expect to have.


Chris, thank you very much for taking your time to answer my question. I will ponder what you said a bit more before deciding on a solution.