[Standards] MUC rooms on roster.

Joe Hildebrand hildjj at gmail.com
Fri Aug 10 05:30:48 UTC 2007


On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote:
> Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ?
> That would still be useful to store non-autmatically-joined MUCs I  
> guess?
> Also that XEP offers also a way to auto-join MUCs.

The more we talked about this around the office, the more we thought  
we only needed two things to make this work for our use cases.

1) A new MUC role which effectively the opposite of visitor.  Of  
course, on the bar napkin, this got written as "rotisiv". :)  A  
rotisiv can potentially speak (broadcasting to all of the members of  
the room), but can't see any of the messages that are broadcast to  
the room.  As well, rotisivs get presence from all of the  
participants and moderators of the room, but nobody receives the  
rotisiv's presence from the room.  Obviously, an implementation might  
want ACLs to specify who can be a rotisiv for a given room.

2) An addition to xep-48 that gives a little more meta-data.

<iq type='set' id='2'>
   <query xmlns='jabber:iq:private'>
     <storage xmlns='storage:bookmarks'>
       <conference name='Council of Oberon'
                   autojoin='true'
                   jid='council at conference.underhill.org'>

	<group xmlns='' role='rotisiv'/>

       </conference>
     </storage>
   </query>
</iq>

Just as for normal MUC, the client sends a separate presence stanza  
to each group they are a participant in or moderator of, whenever the  
user changes presence; this allows a client can use its existing MUC  
and bookmarks implementation to do whatever UI they want, manage  
which groups they appear online to, and the like.  In this case,  
pushing a small amount of complexity down to the client (which the  
client probably already has anyway) leads to a vast simplification in  
the server implementation.  It's very apparent which presence is  
group-related for clients that want to do special UIs, and existing  
clients that haven't implemented the new feature get to participate  
in groups.

-- 
Joe Hildebrand





More information about the Standards mailing list