FYI, I plan to update XEP-0172 along these lines.
Original Message
Subject: Re: [jdev] XEP 0172 in MUCs
Date: Mon, 20 Feb 2012 01:07:47 +0500
From: Waqas Hussain waqa...@gmail.com
Reply-To: Jabber/XMPP software development list j...@jabber.org
To: Jabber/XMPP software development list j...@jabber.org
On Tue, Feb 14, 2012 at 3:54 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
Hallo Thijs,
On 1/4/12 10:26 AM, Thijs Alkemade wrote:
Hello,
As a client developer, I'm a bit confused about how XEP 0172 (User
Nickname) is intended to be used with MUCs. From the XEP:
A user MAY specify his or her persistent nickname as well. This may
be desirable because the user's preferred room nickname is already
taken or because the service locks down room nicknames.
So should a client should interpret the XEP-0172 nickname as a
replacement for the MUC-nickname?
I think it would be supplemental.
This could lead to confusing
situations with the same nick being used multiple times. If the
service locks down room nicknames, then it supposedly has a good
reason for that, and implementing a way to circumvent that sounds
like a bad idea.
I think you're right.
The reason I'm asking this is because Google Talk (the web interface)
uses, for ad-hoc private group chats, random strings as room nicks,
and then sends the user's real name as a nick element. I think all
users would rather see the real name instead of the random string,
but I'm worried about the implications of changing this. I've read
the Security Considerations of XEP-0172, but I don't think that
really answers this.
I agree with you that it's preferable to allow real roomnicks. We might
want to update XEP-0172 to make that clearer, or even deprecate its use
in chatrooms...
I strongly support deprecating its use in chatrooms.
We've seen this cause issues in the Prosody chatroom. This was on my
list of things to post on the standard list, but somehow I never did.
This issue that we saw was different clients showing users different
nicks for the same user, users auto-completing the wrong nick, and
conversations getting derailed due to that. A quick survey of the
participants in that discussion showed that the affected clients had
no visual indication that the nick being displayed and in the UI
wasn't the real room nick. This has obvious security implications,
e.g., it easily allows impersonation.
--
Waqas Hussain
___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___
