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

Vapor vapor at 66oc.org
Sun Sep 22 22:35:29 CDT 2002


After looking over what I wrote below, I think I understand better what most
of you have previously stated.  This is fairly implementation specific and
can be built using what you have already designed for JEP 45.  $Just my
.000002 on the subject.

My only concern was writing a low level protocol that limited this kind of
implementation and I answered my own concerns :-)

Vapor.

----- Original Message -----
>From: "Vapor" <vapor at 66oc.org>
To: <standards-jig at jabber.org>
Sent: Sunday, September 22, 2002 3:33 PM
Subject: Re: [standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)


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





More information about the Standards-JIG mailing list