Problems with MUC in 3.2.0?

I think this problem may have been present in 3.1.x, but I can’‘t remember for certain. When a user joins a MUC on my Wildfire server, then leaves, my client (mcabber) wasn’'t showing any sort of part message. It was, however, showing the appropriate messages on the MUCs on other, non-Wildfire servers. So I dumped the raw XML to see what mcabber was actually receiving.

It seems that, upon the user leaving the MUC, Wildfire is NOT setting the role to “none”. Rather, it’‘s leaving it set to whatever role the user had when they entered the room. So if someone joins who is a moderator (role=“moderator”), when they leave the XEP says it’'s supposed to become role=“none”. But in Wildfire, it stays as role=“moderator”, and confuses clients.

Has anyone else observed this? Thanks!

I’‘ve confirmed this with other Jabber clients too. Have any of you Jive peoples taken a look at this, or are you at least aware of the problem? It’‘s incredibly annoying. I hadn’'t seen a reply to my post yet, so … bumping it. Thanks!

Hey mysticone,

Wildfire does not support the very latest MUC specification. Anyway, I filed JM-974 and checked in a bug fix for this improvement. Although the spec does not explicitly says that the role must be “none” I went ahead and made that change to match the provided examples in the spec. Clients should be able to handle the old implementation just fine since the important part of the presence packet is that it is of type unavailable.


– Gato

Thanks, Gato. I went back to the XEP ( and started reading the different sections on entering/exiting MUCs, and I believe your interpretation is correct. It seems that many client authors have decided to use the role to determine join/part messages, but still use presence to actually show who is and isn’‘t in the room. I didn’‘t realize at first that the role examples given really appear to be examples of the usage of the role, not a guide as to how to use the role to determine room status. But, since a lot of clients also seem to support this somewhat weird usage (and because it makes sense to set the roles depending on the change in user availability), it’'s probably good for Wildfire to implement this as well. Thanks for the reply and for implementing a fix. I appreciate it!