> -----Original Message----- > From: David Sutton [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 2:57 AM > To: [EMAIL PROTECTED] > 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='[EMAIL PROTECTED]'> > > <query xmlns='jabber:iq:browse'/> > > </iq> > > READ: <iq type='result' to='user@server/resource' > from='[EMAIL PROTECTED]'> > > <conference xmlns='jabber:iq:browse' name='room' > type='public'> > > <ns>http://jabber.org/protocol/muc</ns> > > <user name='nick1' jid='user2@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., > '[EMAIL PROTECTED]/nick2'). > > > > > -----Original Message----- > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 8:59 AM > > > To: [EMAIL PROTECTED] > > > 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 > > > '[EMAIL PROTECTED]/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:[EMAIL PROTECTED]] > > > > > Sent: Monday, February 10, 2003 8:51 PM > > > > > To: [EMAIL PROTECTED] > > > > > 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 > > > > > > > > [EMAIL PROTECTED]/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='[EMAIL PROTECTED]/nick1'> > > > > <x xmlns='http://jabber.org/protocol/muc'/> > > > > </presence> > > > > READ: <presence from='[EMAIL PROTECTED]/nick1' > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item affiliation='owner' jid='user@server/resource' > > > > role='moderator'/> > > > > </x> > > > > </presence> > > > > > > > > Changing the nick (JEP-0045, section 6.4): > > > > > > > > SENT: <presence to='[EMAIL PROTECTED]/nick2'/> > > > > READ: <presence type='unavailable' from='[EMAIL PROTECTED]/nick1' > > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item nick='nick2' affiliation='owner' > > > > jid='user@server/resource' role='moderator'/> > > > > <status code='303'/> > > > > </x> > > > > </presence> > > > > <presence from='[EMAIL PROTECTED]/nick2' > > > to='user@server/resource'> > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > <item affiliation='owner' jid='user@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 > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > -- > > > David Sutton > > > Email: [EMAIL PROTECTED] > > > Jabber: [EMAIL PROTECTED] > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > -- > David Sutton > Email: [EMAIL PROTECTED] > Jabber: [EMAIL PROTECTED] > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
