[Standards] Community/MUCol proto-XEPs

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Feb 23 21:44:23 UTC 2007

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


-----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:



> 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 Saint-Andre
XMPP Standards Foundation

More information about the Standards mailing list