[JDEV] MUC problems

[David Sutton]

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/13c6a01dc31309e331c2b018640b9c03b8534327 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20030211/6c78f9f5/attachment-0002.pgp>