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

Pasi Parnanen pasi at parnanen.net
Sun Sep 22 19:53:18 UTC 2002


Hello Nick. 


The protocol has to handle parent/child relationships between rooms.
That's it basically. Without that there's no chance to implement any
hierarchy.

Having the ability to make steps is great when building a pyramid, and a
pyramid would make things easier for the admin. Although the pyramid is
outside this JEP the steps aren't. 

It's important that we make an effort to integrate the rooms with the
browsing so that a person can go through rooms to get to other rooms
with a chance of diversions happening. (we already have a browse list
for jumping directly to a certain room, no need to change that).

The participant shouldn't wind up in a mute list when kicked, but in the
parent room among other participants. 

We think the protocol should reflect that. 


-- BlackDog
The shortest path is straight - the funniest isn't .



Nick:
> Maybe you can help me here. What exactly is the point of a tree like 
> system of rooms? That is very very implementation specific. Not exactly 
> idea for a protocol...
> 
> 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
> >  
> >
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig





More information about the Standards mailing list