[Standards] Should we move Nicks out of MIX-CORE?

Sam Whited sam at samwhited.com
Mon Jun 4 16:29:25 UTC 2018


On Sun, Jun 3, 2018, at 14:10, Daniel Gultsch wrote:
> 2018-06-03 18:22 GMT+02:00 Steve Kille <steve.kille at isode.com>:
> > My sense is that it is handy to have Nicks associated with channel participants, to give a more compact display.  Perhaps this reflects the UIs I'm used to.   It feels a pretty basic capability to me.

Having some sort of nick seems sensible if the alternative is me having to set a name for each of my contacts in my roster.

> My issue with nicks in non-anonymous group chats (and MIX core is now
> going to be non-anonymous by default) is that you loose the single
> source of truth on what to name that participant.
> If I have you in my contact list and I have given you a custom name I
> have probably done that for a reason and in 1:1 chats with that person
> I will always see that custom name; But how should this be handled in
> group chats then? Should it display the nix? Should it display the
> roster name?

This doesn't seem to be a mix specific problem. My view has always been that I get to make decisions about what my client shows, so what I set in my roster overrides what my contacts send to me. So the fallback is Roster Name -> Remote Nick -> Other identifier (probably JID local part or similar). This also works well because it means that if I don't care what my contacts look like I don't necessarily have to rename each and every one of them (they do it for themselves once and it gets broadcast), but if I do rename all of my contacts (I do "Firstname Lastname" personally) then it's no different, but at least I don't have to look at a JID in the mean time.

> In any case; We don’t necessarily need to have a discussion on whether
> channel nicks are a good idea or not; Instead I’d rather make the
> argument that MIX promotes itself as being an extensible and flexible
> solution; so if it is technically possible to move nicks into it's own
> XEP it should be done.
> 
> > However,  I could move it out into a new MIX-NICK.   What do people think?
> 
> Yes let’s put it into a separate XEP

I tend to disagree with this; splitting out all these optional parts makes the MIX core smaller, which is definitely nice, but I'm not convinced it actually makes it any easier to implement or understand (see the examples I gave in my previous email to this list). In this particular case, nick setting is a small simple enough section and, I suspect, such a common feature that moving it out will just mean that people have to go dig it up, or will think that MIX doesn't support it and will use it as a reason not to implement MIX. The fact that there are currently 7 MIX XEPs is part of the complexity, not a fix for it.

On a tangentially related note:

> The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following RFC 4122 [17].

This seems unnecessary and a terrible UX to the point where I'm wondering if maybe I'm misunderstanding something and this doesn't mean "Show UUIDs to users"?

—Sam


More information about the Standards mailing list