[Standards] Community/MUCol proto-XEPs

Peter Saint-Andre stpeter at jabber.org
Tue Feb 27 01:24:59 UTC 2007

We had a good discussion about this at the "XMPP Summit" today. I'll 
soon write up some of the approaches we discussed.

Joe Hildebrand wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070227/48a37de1/attachment.bin>

More information about the Standards mailing list