[jdev] XEP 0172 in MUCs
waqas20 at gmail.com
Sun Feb 19 20:07:47 UTC 2012
On Tue, Feb 14, 2012 at 3:54 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Hallo Thijs,
> On 1/4/12 10:26 AM, Thijs Alkemade wrote:
>> 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.
More information about the JDev