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

Vapor vapor at 66oc.org
Sun Sep 22 15:33:51 CDT 2002


I worked with BlackDog in the jabber rooms helping to develop this idea.
BlackDog though did most of the work though.  But I have a question then
concerning this jep.  If I am reading the other emails correctly, JEP 45 is
ment to be the lowest level protocol for conference servers that other JEPs
can be built off to add further functionality.  I guess though, I share
blackdog's concern, that if there isnt something in place to in this JEP,
that it will limit what latter JEP's will be able to allow for.  For
example, IPv4, no matter how well developed, is still utimately limited by
the fact that it has only 32bits for its addressing.  A whole new IP
protocol had to be developed to support more address space due to this
limitation.  IPv6 has difficulty being backward compatible with IPv4.  Had
IPv4 been written to support more address space in the beginning, there
wouldnt have been quite the same need to develop a whole new IP protocol.

So following that same thought process, if in JEP 45, the fundamentals at
least perscribed the building blocks needed for the heirarchy system, then
that might satisfy both sides.

For example. What if you used a jid like jabber at jabber.org for the parent
folder.  and room1.jabber at jabber.org for a sub folder/room then it could be
both backwards compatable as well as compatible with the new idea of room
heirarchy.

A room 2 levels down would be subroom1.room1.jabber at jabber.org and so on.

Just a thought, but if it mentioned this kind of standard in JEP 45, then a
later JEP could delve deaper into impementing it without breaking
compatibility.

(assuming I understand the technology correctly)

Jared Cluff (vapor)

----- Original Message -----
>From: "Pasi Parnanen" <pasi at parnanen.net>
To: <standards-jig at jabber.org>
Sent: Sunday, September 22, 2002 2:53 PM
Subject: Re: [standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)


> 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
>
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
>





More information about the Standards-JIG mailing list