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

Pasi Parnanen pasi at parnanen.net
Sun Sep 22 13:11:36 CDT 2002


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





More information about the Standards-JIG mailing list