Thanks Kirk and Matthew, That's the same conclusion I think I have come to - to override the normal response to a disco info request on the MUC service to return a different room set depending on whether the user is a MUC admin or not. I was hoping to avoid a server specific implementation as that ties me further to our choice of chat server, but in this case it seems like the right thing to do.
Thanks for your help Michael On 12 Mar 2012, at 15:59, Kirk Bateman <[email protected]> wrote: > Hi guys, > > Back when Buddycloud was using MUC as the backend for channels, I implemented > pretty much what you are talking about. Matthew is correct, its just > implementation stuff :) > > We were using Palaver as the MUC backend on an ejabberd server, a global > admin "user" capable of deleting, kicking users etc was essentially set as > the owner of all channels during creation, we added things like complete > channel logging to a DB directly in the Palaver implementation source, and > also I remember modifying the channel list discovery code so it only returned > public channels (as we had private user channels too). > > Hope that helps. > > Cheers > > Kirk > > On 12 March 2012 15:52, Matthew Wild <[email protected]> wrote: > Hi, > > On 12 March 2012 13:33, Michael McCarthy <[email protected]> wrote: > > Hi all, > > > > We're big users of MUC here, and we use the public and non public features > > of MUC rooms to give the impression of them being open and closed at certain > > times. > > > > My question is, is there any way a MUC admin could browse the list of rooms > > including hidden rooms? We currently have to do this using our server's API, > > and we'd prefer to avoid that and use XMPP components if it all possible. > > > > I think this is rather more a question of implementation than > protocol. A server is quite capable of displaying hidden rooms to > admins without any change in the protocol. > > And you are right, service admins are also beyond the realms of the > protocol, though I think the spec hints at the possibility of service > admins if I recall correctly. Again, it's something the implementation > is free to provide. > > Regards, > Matthew >
