[Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

Ненахов Андрей andrew.nenakhov at redsolution.ru
Fri Nov 30 07:10:53 UTC 2018

For anyone's interested, in our group chat protocol we did the following
(and it's already working!):

   - Every user is assigned an id valid only for this group chat, this id
   does not carry any semantic value and are to be unique
   - Chats can be in regular or incognito mode. In regular mode user's XMPP
   IDs are visible, in incognito mode - no
   - Regular chat users can opt to group chat server harvesting data from
   their vCards and setting up group chat nick/avatar to match user's current
   nick/avatar, or to manually submit their own nick/avatar. Doing so cancels
   automatic gathering of user data
   - Nicknames are NOT unique, if second person sets a nickname matching
   that of someone's else, we add a special *badge* to this user (usually
   displayed near nick), so that combination of nickname+badge is always uniqie
   - btw, in chats where users can set the badge themselves, the most
   popular badge that users set is 💩. By a large margin.

чт, 29 нояб. 2018 г. в 17:12, Daniel Gultsch <daniel at gultsch.de>:

> Hi,
> I’ve been reading (parts of) MIX again. I might share some stray
> observations at some point (Like why isn’t the submission-id not
> reusing the origin-id) but those are all rather insignificant.
> Today I want to discuss something else that has been worrying me for
> quite a while. I have mentioned that in a thread somewhere but it
> didn’t get a lot of attention.
> I understand that a lot of the core designers of MIX are mostly after
> 'something like Slack' or other work place-y things. However I’m
> coming from a 'personal IM' usecase aka 'The WhatsApp Clone' and I
> feel that some of my use cases are not covered very well by MIX and I
> would appreciate if MIX could cover my use case as well and not brush
> it of as and afterthought just-do-an-extension-later kind of problem.
> (By the way I’m not just talking as the developer of Conversations
> here but as someone who implements 'proper' closed source
> non-federating WhatsApp clones.)
> So let me paint you a picture of my use case. In WhatsApp the user
> creates an account; usually tied to a phone number - but that’s not
> the point; and sets a Name and an Avatar. That name isn’t unique. It
> would be pretty stupid if WhatsApp would prevent me from calling
> myself 'Daniel' and would force me to call myself 'Daniel12345'. That
> name and avatar is my identity on that chat system. When I’m in a
> group chat with someone I’m still holding on to that identity. People
> in that group chat expect to see that name and that avatar.
> So when it comes to MUC my 'Identity Name' doesn’t map to MUC nick
> names. MUC Nick names are unique. My identity name might not be. So
> usually when I create WhatsApp-like group chats I set the nick to
> something unique (most of the times the local part of my JID) and then
> simply never display it but gather the 'true identity' by other means.
> (Those other means can become pretty complicated and hacky)
> So MIX in that regard is pretty close to MUC in that nick names are
> unique for example. At least they are are somewhat optional. They are
> not as much second class citizens as I would hope they would be - but
> at least they are optional enough that I can ignore them.
> But if I ignore them I have to discover the true identity of a JID
> somehow. (That is display name (stored in a PEP node for example) and
> avatar.
> In previous talks about MIX we have discussed creating 'avatar' and
> other nodes on the mix channel. However even if we have those it would
> basically mean that if I change something on my avatar or display name
> I would then need to change them on every MIX channel I’m joined in.
> That is pretty bad.
> So one wild idea would be to do some automatic PEP subscription thing.
> So the PAM - who knows what real JIDs I’m in channels with - would
> automatically subscribe me to their PEP nodes. And only once per JID -
> even if I'm in multiple rooms with that person - and then unsubscribe
> me once I’m no longer in a group with that person (either because I
> left those groups or because they left.) - Something like that.
> I don’t want to narrow it down to that particular solution; I’m open
> for everything. However I just wanted to describe that use case - I
> think it is an important use case - that may or may not be on the
> minds of the 'people behind MIX' that really needs a first class
> solution. (As opposed to leaving this to some random extensions
> someone in the future might come up with.)
> cheers
> Daniel
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181130/db992e91/attachment.html>

More information about the Standards mailing list