[JDEV] MUC problems
Constantin Nickonov
Nickonov at jabber.com
Wed Feb 12 09:19:56 CST 2003
> -----Original Message-----
> From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> Sent: Wednesday, February 12, 2003 2:57 AM
> To: jdev at jabber.org
> Subject: Re: [JDEV] MUC problems
>
>
> Hi there,
>
> I can understand your point as well, so have come up with this
> compromise. When you browse a room, the jid given will be
> the room jid
> + nick. What happens if you browse further depends on the
> room. If the
> room is unanonymous, or you are a room admin, then you will see the
> users real jid. If you are a normal user and not allowed to see real
> jids, then you will see the SHA hash jid version. That way
> we keep to
> the spirit of the jep, whilst allowing tracking of user->nick
> relations.
>
> This has been checked into the mu-conference cvs. Does this
> sound good
> to you?
And where else will the SHA-hashed version of the JID be used? Can clients
send directed messages, etc., to the SHA-hashed version? I really don't
see the need to "track people" in this way. In the end, if the room is
anonymous, a user shouldn't really be "trackable" when in it. If it's
non-anonymous, you have the real JID and don't need to complicate things
(which you've already conceded).
The two-phase browse seems like a good idea, i.e., get the in-room JID
from a room browse, and then dig deeper for the user's real JID by
browsing to the in-room JID.
>
> Regards,
>
> David
>
> On Tue, Feb 11, 2003 at 10:28:55AM -0700, Constantin Nickonov wrote:
> > I understand what you're trying to do. The problem is that
> your methods
> > conflict with the intent of JEP-0045, which will eventually
> result in
> > fragmentation of the standard, i.e., when two or more
> implementations of MUC
> > accomplish the same thing in incompatible ways. Perhaps the
> JEP should be
> > more specific when it comes to laying out the 'jabber:iq:browse'
> > capabilities (which are being phased out in favor of
> disco), but it seems to
> > me the re-introduction of SHA-hashing for this purpose is
> not a good thing.
> >
> > Sure, you can talk about race conditions, like when I
> browse to get a list
> > of users and one of them chooses that moment to change his
> nick, making my
> > subsequent user-level browse requests invalid. But why not
> just return the
> > real JID (if it's allowed by the room) in the room-level
> browse result?
> > Something like this:
> >
> > SENT: <iq type='get' to='room at muc.server'>
> > <query xmlns='jabber:iq:browse'/>
> > </iq>
> > READ: <iq type='result' to='user at server/resource'
> from='room at muc.server'>
> > <conference xmlns='jabber:iq:browse' name='room'
> type='public'>
> > <ns>http://jabber.org/protocol/muc</ns>
> > <user name='nick1' jid='user2 at server/resource'/>
> > </conference>
> > </iq>
> >
> > In the case of an anonymous room, the 'jid' attribute could
> be omitted (or
> > contain the in-room JID for that user, i.e.,
> 'room at muc.server/nick2').
> >
> > > -----Original Message-----
> > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > Sent: Tuesday, February 11, 2003 8:59 AM
> > > To: jdev at jabber.org
> > > Subject: Re: [JDEV] MUC problems
> > >
> > >
> > > Hello there,
> > >
> > > We are both correct in this situation. The JEP does define
> > > how the jid
> > > is to be handled for a presence packet, and
> MU-Conference follows
> > > that. You will never see the SHA1 string in a presence packet.
> > >
> > > On the other hand, the system of using an iq request, xmlns
> > > jabber:iq:browse, to discover the room roster is not
> covered by the
> > > JEP. In order to maintain sanity, I have opted to
> continue using the
> > > existing methods. If you require to see the real jid,
> and you are
> > > allowed, then browsing the SHA1 resource will reveal
> the true jid. I
> > > have to use the sha1, since it allows you to track the user more
> > > consistantly - as I tried to explain before, I could use
> > > 'girls at conference.localhost/NICK' for the nickname reported
> > > by browse,
> > > the problem is that if users swap nicknames, I have no way
> > > of knowing
> > > that is what happened. The SHA1 string is unique to that user.
> > >
> > > Regards,
> > >
> > > David
> > >
> > > On Tue, Feb 11, 2003 at 08:12:16AM -0700, Constantin
> Nickonov wrote:
> > > > see below
> > > >
> > > > > -----Original Message-----
> > > > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > > > Sent: Monday, February 10, 2003 8:51 PM
> > > > > To: jdev at jabber.org
> > > > > Subject: Re: [JDEV] MUC problems
> > > >
> > > > <snip>
> > > >
> > > > > The hex string is actually a SHA1 hash of the users real
> > > jid. Its used
> > > > > to reference a user, but not reveal the true jid. If the room
> > > > > is set up to allow people to see the real jid, then
> just browse
> > > > >
> > > girls at conference.localhost/13c6a01dc31309e331c2b018640b9c03b85
> > > 34327 and
> > > > > it will show you the true jid. This also helps to keep
> > > compatability to
> > > > > existing clients that are used to this form with the
> > > > > groupchat/conferencing module. The real jid is used as
> > > the reference, as
> > > > > a person can keep changing their nick throughout a
> > > session, but they
> > > > > can't change their real jid
> > > >
> > > > The problem with this is that the MUC standard (JEP-0045)
> > > specifies how
> > > > nicknames are passed along with presence information, and
> > > how they are
> > > > changed -- and SHA-hashing isn't the way.
> > > >
> > > > Entering a room (JEP-0045, section 6.2):
> > > >
> > > > SENT: <presence to='foo at muc.server/nick1'>
> > > > <x xmlns='http://jabber.org/protocol/muc'/>
> > > > </presence>
> > > > READ: <presence from='foo at muc.server/nick1'
> > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item affiliation='owner' jid='user at server/resource'
> > > > role='moderator'/>
> > > > </x>
> > > > </presence>
> > > >
> > > > Changing the nick (JEP-0045, section 6.4):
> > > >
> > > > SENT: <presence to='foo at muc.server/nick2'/>
> > > > READ: <presence type='unavailable' from='foo at muc.server/nick1'
> > > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item nick='nick2' affiliation='owner'
> > > > jid='user at server/resource' role='moderator'/>
> > > > <status code='303'/>
> > > > </x>
> > > > </presence>
> > > > <presence from='foo at muc.server/nick2'
> > > to='user at server/resource'>
> > > > <x xmlns='http://jabber.org/protocol/muc#user'>
> > > > <item affiliation='owner' jid='user at server/resource'
> > > > role='moderator'/>
> > > > </x>
> > > > </presence>
> > > >
> > > > The MUC protocol wasn't designed to be fully
> > > backward-compatible with the
> > > > JCF draft.
> > > >
> > > > Constantin
> > > > _______________________________________________
> > > > jdev mailing list
> > > > jdev at jabber.org
> > > > http://mailman.jabber.org/listinfo/jdev
> > >
> > > --
> > > David Sutton
> > > Email: dsutton at legend.co.uk
> > > Jabber: peregrine at legend.net.uk
> > >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
>
> --
> David Sutton
> Email: dsutton at legend.co.uk
> Jabber: peregrine at legend.net.uk
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
More information about the JDev
mailing list