[standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)

Peter Saint-Andre stpeter at jabber.org
Mon Sep 23 11:15:09 CDT 2002 

This post well states my thoughts on the subject. While I think that a
hierarchical organization of rooms makes sense in some contexts, JEP 45
says nothing abotu how you find the JID of a room. It could through
browsing (in which case a hierarchy makes sense), it could be from
receiving an email, it could be from a web page, etc. I really do see this
hierarchy issue as orthogonal to the base protocol we're defining in JEP
45. If anything it has to do with browsing and some of the pub/sub pieces
DJ talked about recently, not the base groupchat protocol. I'm open to
argument but right now I'm just not seeing the connection.

Indeed, I would go so far as to say that discovery of a JID (whether that
JID be a room or a person or some other entity) is utterly separate from
how you subsequently interact with that JID (send it messages, receive its
presence, etc.).

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.html

On Sun, 22 Sep 2002, David Sutton wrote:

> Hi there,
> 
>   Part of the issue is that we need a base protocol in place first, as
>   several components require a standard method of communicating with
>   jabber clients, and this is what the jep is designed to cover. What
>   you are describing is a particular implementation which makes
>   assumptions on how it will be used. This is not a bad thing, but the
>   aim is different to the one of the jep. What you could do is take this
>   jep as an example, give credit where credit is due, and use it to help
>   develop documentation and a proposal for your system. This jep defines
>   communication between two entities, not the conference service, if
>   that makes sense to you.
> 
> Regards,
> 
>   David
> 
> On Sun, Sep 22, 2002 at 08:11:36PM +0200, Pasi Parnanen wrote:
> > Thanks for reading my proposals, David. 
> > 
> > 
> > Minimal change was one of the restrictions we were working with in the
> > talks on jabber at jabber.org. We wanted extended functionality with as
> > little change to the conference system itself as possible. Mainly
> > because we didn't know how much of the conference code that could be
> > altered... We planned on using a web page for the tree of places and
> > bots to take care of authentication.
> > 
> > We try our best to understand that there has to be compatibility between
> > conf 1.0 and 2.0 requests, but hope that it will be so in a upward
> > manner, without setting limits on new and badly needed functionality. 
> > 
> > Voice, like it now stands in JEP-45:0.6, is such a new function as well
> > as kick and ban. All three would need to have new interactions. But is
> > this the only functionality we need to have added? The ability to create
> > rooms is present in the v.1, but we also need to restrict that in v.2.
> > 
> > The introduction of a hierarchical system for the rooms would create a
> > simple, yet capable system for administering the rights for groups of
> > rooms. To allow the administrators to take full advantage of this
> > hierarchy the only necessary addition would be to allow (child) rooms
> > within the room. The parent rooms would indeed be out of the scope of
> > this JEP, which is slightly strange. What is the JEP for that, btw?
> > 
> > The result of being kicked would also be more logical with a
> > hierarchical approach. The participant would not be thrown off the
> > server but merely yanked out of the room and into the parent room. This
> > would increase the "staying-factor", i.e. the participant would stay
> > with the same site better. The participant would also meet more people
> > because there would be people in the room he or she was "kicked" into. 
> > 
> > Having a hierarchy would also increase the "cross-pollination" of rooms
> > and allow similar rooms to link to each other. Both by grouping rooms
> > logically and by adding symbolic links between rooms. We think it would
> > increase the number of visitors. Even with the same number of
> > participants we would seem to have more people in the jabber conference
> > (compared to other systems) because the flow of people would be more
> > visible. The corridors wouldn't be mute, as we call it. With IRC and
> > conference v.1 the corridors are.   
> > 
> > The visitor could even pick a home room to go to, like *nix users have
> > home catalogs. A virtual cubicle, perhaps? Or a penthouse?
> > 
> > 
> > If we implement kick, ban and room creation now without having a
> > hierarchy then the chance of having the hierarchy later will die from a
> > horrid downwards compatible recursive curse... That functionality will
> > for ever be stuck in it-works-so-why-change-it-limbo.
> > 
> > We think jabber conferences deserve better.
> > 
> > 
> > -- Pasi "BlackDog" Parnanen
> > 
> > 
> > 
> > David Sutton:
> > > I get an idea of what you are trying to achieve, but in some respects
> > > I feel its beyond the realms of this jep. One of the core aims is to
> > > ensure compatibility with the existing GroupChat v1 code. What you are
> > > proposing, although an interesting concept, would be hard to keep that
> > > goal with. My attitude has been 'fix what we have now, and then once
> > > we're stable, we can create new, advanced conferencing protocols safe
> > > in the knowledge that what we have works now' and I still believe that
> > > now. 
> > > 
> > >   In the end, it is up to Peter Saint-Andre, but thats my feelings on
> > >   the matter :)
> > > 
> > > Regards,
> > > 
> > >   David
> > > 
> > > On Sun, Sep 22, 2002 at 11:44:01AM +0200, Pasi Pärnänen wrote:
> > > > David Sutton (in response to Peter Saint-Andre):
> > > > > Ok, regarding roles - does admin imply voice, or should two roles 
> > > > > elements be given, one for admin and one for voice? Actually, in the 
> > > > > examples, you have voice as a seperate element - should it not be a 
> > > > > role?
> > > > 
> > > > 
> > > > In the talks in the jabber room the method was to compare the collection
> > > > of rooms with a folder hierarchy.
> > > > 
> > > > 
> > > > Thus... 
> > > > 
> > > > Each room (or "place") would have:
> > > > owner - admin - participant
> > > > access - voice - create
> > > > savcavcavc
> > > > 
> > > > ...compared to:
> > > > user - group - other
> > > > read - write - execute
> > > > lrwxrwxrwx
> > > > 
> > > > 
> > > > Example actions:
> > > > 
> > > > kick:
> > > > Temporary remove access to place and send to parent place.
> > > > 
> > > > block:
> > > > Remove access to place and send to parent place.
> > > > 
> > > > ban: 
> > > > Remove access to all conference places and terminate session.
> > > > 
> > > > mute:
> > > > Remove voice.
> > > > 
> > > > speak: (a better word must exist)
> > > > Remove voice from all participants in the room except one.
> > > > (useful for moderated places)
> > > > 
> > > > hush:
> > > > Remove voice from all participants.
> > > > 
> > > > promote: 
> > > > Make the participant an admin in this place (and in subsequent places).
> > > > 
> > > > degrade: 
> > > > Make the admin a participant in this place.
> > > > (only available to owner of root place)
> > > > 
> > > > dub:
> > > > Make the participant an admin of the entire conference.
> > > > (only available to owner of root place)
> > > > 
> > > > deface:
> > > > Remove all admin rights for user. (all rooms in conference)
> > > > (only available to owner of root place)
> > > > 
> > > > etc...
> > > > 
> > > > 
> > > > The create right would give the owners, admins and in some places even
> > > > the participants the right to create new places, a bit like folders
> > > > within folders.
> > > > 
> > > > The browse places could then be used in a manner similar to looking at a
> > > > file system tree, maybe even with the number of users in each place
> > > > visible.
> > > > 
> > > > 
> > > > In *nix, everything is a file, and our idea was that in the conference,
> > > > everything would be a place. With the idea of having a "tree of rooms"
> > > > we could even have quick shortcuts between places within the conference,
> > > > if we want to. 
> > > > 
> > > > parent:
> > > > pavcav-a--	stpeter gods 	12 	throneroom
> > > > 
> > > > shortcut:
> > > > savcav-a--	stpeter gods 		audiences -> ../../throneroom
> > > > 
> > > > place:
> > > > -avcav-av-	da_king guards 	 3	oubliette
> > > > 
> > > > 
> > > > The "tree of places" would be fairly easy to understand for newcomers
> > > > too, we think. 
> > > > 
> > > > 
> > > > -- Pasi "BlackDog" Parnanen
> > > > -- If there is blame then cast it upon me and not upon the innocent. 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Standards-JIG mailing list
> > > > Standards-JIG at jabber.org
> > > > http://mailman.jabber.org/listinfo/standards-jig
> > > 
> > > -- 
> > > David Sutton
> > > Email: dsutton at legend.co.uk
> > > Jabber: peregrine at legend.net.uk
> > 
> > 
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> 
> -- 
> David Sutton
> Email: dsutton at legend.co.uk
> Jabber: peregrine at legend.net.uk
>

More information about the Standards-JIG mailing list