[Standards] Community/MUCol proto-XEPs

Joe Hildebrand hildjj at gmail.com
Fri Feb 23 22:45:15 UTC 2007


I like the idea of using XEP-115 to tell the client that this contact  
has an attached community, then allowing the client to retrieve the  
community list with an iq/get, which turns on community pushes (like  
roster pushes, but in a different namespace) and retrieves the  
current list.

Just doing roster pushes from the community has a couple of downsides:
- Communities could only exist on local, trusted components
- Clients that set a nickname, for instance, would probably end up  
modifying the "real" roster as a side-effect
- It would be difficult to tell which contact went with which  
community, or whether the contact was a part of a community at all.   
XEP-115 wouldn't work for this, since a) the contact might not be  
online, b) the community might only want to you to see that they are  
a member of the group, not that person's presence, and c) XEP-115  
should describe their client's capabilities, not that of the  
community they are in.

On Feb 23, 2007, at 2:44 PM, Jean-Louis Seguineau wrote:

> I like the community approach as well, and I would also prefer  
> something
> working along the lines of the current rosters. As Peter mentioned  
> rosters
> are rather "dumb", and if I understand well he propose to hold the
> community's JID in the roster, not the actual community members'  
> JID. I was
> wondering if the community server could not just push the user's  
> community
> roster to the client upon receiving the user initial presence  
> (doing an IQ
> set) instead of the user retrieving the roster (doing an IQ get).
> Alternatively, we could imagine that the community server overload  
> its own
> initial presence to the user with an XEP-115 capability extension  
> to tell
> the user's client to fetch the community roster.
>
> My two cents
>
> Jean-Louis
>
> -----Original Message-----
> Message: 1
> Date: Tue, 20 Feb 2007 12:11:50 -0700
> From: Peter Saint-Andre <stpeter at jabber.org>
> Subject: Re: [Standards] Community/MUCol proto-XEPs
> To: XMPP Extension Discussion List <standards at xmpp.org>
> Message-ID: <45DB47F6.1010601 at jabber.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> James Tomson wrote:
>
>> Our company is currently developing an IM solution specifically
>> designed for education, based on XMPP. In a nutshell, the IM client
>> will display all of the courses a user is enrolled in, and for each
>> course, a list of classmates including their roles (student,
>> instructor, teaching assistant, etc...). Users will have their
>> classmates pre-populated in their rosters and receive their presence,
>> without having to manually add them.
>>
>> We have not found a satisfactory way to achieve this in a scalable
>> fashion using standard XMPP conventions, as we will potentially deal
>> with individual rosters of 1000+ contacts, with varying "roles" for
>> contacts within their groups (courses in our specific case). We are
>> investigating strategies to "offload" the processing of large rosters
>> onto external components that communicate with XMPP servers, similar
>> to MUC.
>>
>> Toward this end, we would like to put forward a prototype XMPP
>> extension proposal that addresses our use cases in the more general
>> sense of "communities". Hopefully others looking to implement similar
>> systems will be able to interoperate with each other in the future,
>> and help us to determine if we're off-base in our approach and the
>> solution can be better addressed via other means (e.g. PubSub, which
>> we are investigating as well).
>>
>> Our proto-XEP for "community" support can be found at:
>> http://www.horizonwimba.com/labs/xeps/community.html
>
> We had some discussions about this last fall (some people call it
> "shared groups" or "roster fragments" but I prefer "communities"). I
> haven't read your proposal yet, but my thought is that from the client
> perspective, the easiest way to do communities would be:
>
> 1. Log in, retrieve roster (which include communities), send presence.
>
> 2. When roster or specific community definition changes, receive push.
>
> None of this PEP or iq:private stuff, too complicated. That means
> putting communities in your roster. So I think you'd do this:
>
> 1. Disco to find a groups service and associated communities.
>
> 2. Register with a community of interest.
>
> 3. Community sends you presence subscription request.
>
> 4. Your client approves ('from' only is needed).
>
> Unfortunately, rosters are stupid (everything just looks like a JID,
> i.e., a user JID) so how do you know what the communities are from  
> which
> to retrieve members when you log in? (We have the same problem now  
> with
> transports.) Do we overload the 'name' attribute in iq:roster? Ick.
>
> Anyway that seems like the simplest approach. Whether it's workable is
> another story.
>
> BTW we could use something similar for MUC auto-join:
>
> 1. Register with room.
>
> 2. It sends you presence subscription.
>
> 3. When you log in, room sends you invite.
>
> Something to talk about at FOSDEM / devcon.
>
>> Additionally we will have a software engineer from our company, Yann
>> Biancheri, at the upcoming FOSDEM 2007 conference in Brussels,  
>> Belgium
>> on Feb 24th & 25th, at and the XMPP DevCon on the 26th. He is very
>> anxious to discuss our proposals with anyone who is interested :)
>
> Cool, see you there:
>
> http://wiki.jabber.org/index.php/FOSDEM_2007
>
> http://wiki.jabber.org/index.php/DevCon
>
>> As an aside, we are also looking to extend MUC in order to support  
>> the
>> concept of collaborative media in multi-user scenarios
>> (voip/video/appsharing/whiteboarding etc...), which my colleague
>> Hugues Pisapia has discussed previously on this mailing list. An
>> updated revision of this proto-XEP can be found at:
>> http://www.horizonwimba.com/labs/xeps/mucol.html
>
> Thanks, I'll read it on the plan to Brussels.
>
>> We look forward to any feedback, and don't forget to track down Yann
>> at FOSDEM or DevCon if you'd like to discuss these proposals (he may
>> even be buying drinks - so it's win-win!).
>
> Yes, let's discuss. :)
>
> Peter
>
> -- 
> Peter Saint-Andre
> XMPP Standards Foundation
> http://www.xmpp.org/xsf/people/stpeter.shtml
>
>




More information about the Standards mailing list