[Standards] Community/MUCol proto-XEPs
stpeter at jabber.org
Tue Feb 20 19:11:50 UTC 2007
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:
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
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:
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. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards