[Bug 14540] Names interface - Aliasing replacement with separate nickname, local alias etc.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=14540

--- Comment #16 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-03-07 03:36:35 UTC ---
Comment on attachment 56334
  --> https://bugs.freedesktop.org/attachment.cgi?id=56334
proposed patch

Review of attachment 56334:
 --> (https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=14540&attachment=56334)
-----------------------------------------------------------------

::: spec/Connection_Interface_Names.xml
@@ +2,5 @@
> +<node name="/Connection_Interface_Names" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
> +  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
> +  <tp:copyright>Copyright © 2009 Nokia Corporation</tp:copyright>
> +
> +  <interface name="org.freedesktop.Telepathy.Connection.Interface.Names.DRAFT">

In current spec technology this should be Connection.Interface.Names1

@@ +17,5 @@
> +          account is created or at any time</li>
> +        <li>an alias (<em>local alias</em>) assigned privately by the local
> +          user and stored in the local user's contact list</li>
> +        <li>an abbreviated/less-precise form of their unique identifier
> +          (<em>pretty ID</em>)</li>

I'm less convinced about the pretty ID, see below.

@@ +60,5 @@
> +        display in an address book or list of contacts if no local alias
> +        or nickname is available.</p>
> +    </tp:docstring>
> +
> +    <method name="GetNicknames" tp:name-for-bindings="Get_Nicknames">

Not sure if there's much point in this method, we could just say "use
GetContactAttributes". At the moment the contact attr is defined in terms of
the method, but it needn't be.

@@ +98,5 @@
> +        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
> +      </tp:possible-errors>
> +    </method>
> +
> +    <method name="RequestNickname" tp:name-for-bindings="Request_Nickname">

This can't be replaced by a contact attr, because it blocks.

@@ +111,5 @@
> +            for the method to return), and can distinguish between various
> +            error conditions.</p>
> +
> +          <p>This method is also appropriate for detection of whether a
> +            locally-configured nickname should be set on a server.</p>

I think this + the semantics of Nickname are sufficient to get a competent
implementation in MC, but we need to think about this.

@@ +232,5 @@
> +            >XEP-0165 "Best Practices to Discourage JID Mimicking"</a>).</p>
> +
> +        <p>Connection managers SHOULD NOT use the same storage for names
> +          not assigned by the local user, since this would undermine the
> +          anti-spoofing benefits of storing a user-selected alias.</p>

Gabble currently violates this for performance reasons, by caching remote
users' nicknames in the roster (once) to avoid having to download their vCard
every time. We should think about whether it can do better.

Perhaps downloading everyone's vCard once, and putting it in ~/.cache, would be
sufficient...

@@ +268,5 @@
> +      <tp:docstring>
> +        <p>Sets a user-defined alias for a contact. Clients SHOULD NOT call
> +          this method for names not assigned by the local user, since this
> +          would undermine the anti-spoofing benefits of storing a
> +          user-selected alias.</p>

I think it's OK for UIs to pre-fill an input box for this (e.g. when adding
contacts), but they should always show the user the identifier and an input
box, and only SetLocalAlias on user confirmation.

@@ +310,5 @@
> +      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
> +        <p>If this attribute on a contact is present in the result of
> +          GetContactAttributes, its value is a protocol-specific abbreviated or
> +          formatted version of their self-assigned unique identifier, which may
> +          be more appropriate to display in a user interface.</p>

This contact attribute is really two things, and perhaps we should split them.

1) De-normalized identifier

Use cases: the IRC user whose name normalizes to robot101 wants to appear as
Robot101 in UIs (IRC is case-insensitive). The AIM user whose name normalizes
to pseudorandomcouk wants to appear as "pseudorandom co uk" in UIs (yes, AIM is
space-insensitive).

In these cases, if you normalize the user-chosen name, you get back to their
"real" identifier. It would be reasonable to have your UI only display
"Robot101" or "pseudorandom co uk", and have no way to get back to "robot101"
or "pseudorandomcouk".

2) Abbreviated identifier

Use cases: XMPP clients abbreviate magical.trevor at gmail.com to magical.trevor.
IkiWiki abbreviates OpenIDs like http://frank.livejournal.com/ to "frank
[livejournal.com]" and it would be entirely reasonable for a hypothetical
OpenID-based IM protocol to do the same.

In these cases, you're losing information for the sake of UI clarity. This
would be appropriate for a "list of participants" sidebar in a chat, or a
default display-name in an address book, or something, but you should be able
to disambiguate via the real identifier somehow (maybe a tooltip).

It's not necessarily necessary to split this, though, since UIs could have a
heuristic: try normalizing the pretty-id. If you don't get back to the
identifier, make sure you make the real identifier available too.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.