Bug 33589 - Channel-specific nicknames
Summary: Channel-specific nicknames
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/jo...
Whiteboard: review-
Keywords: patch
Depends on:
Blocks: 33048
  Show dependency treegraph
Reported: 2011-01-27 05:49 UTC by Jonny Lamb
Modified: 2019-12-03 20:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Jonny Lamb 2011-01-27 05:49:30 UTC
To really fix bug #33048 we need to be able to do two things:

 1. change your nickname in an XMPP MUC.
 2. join an XMPP with a specific nickname.

I've implemented this using a method and a property:

Chan.I.Group.SetOwnNickname(s): simply sets your own nickname in the channel if the protocol supports it. The nickname is changed when SelfHandleChanged is fired. This fixes #1.

Conn.I.RoomNickname.DRAFT.DefaultNickname: s, rw: a DBus property connection manager property (so it can be persistent). This fixes #2 by having a global nickname that is used when you join rooms. If it's the empty string then gabble will make up the nickname like it's been doing for years.

Neither of these will fix the case of you wanting different nicknames for different XMPP MUCs which you want set when you join them. tbh I think we should fix that when/if we need to.

Whaddya think?
Comment 1 Jonny Lamb 2011-01-27 05:57:39 UTC
Alternatively, we could put this Conn.I.RoomNickname interface in gabble and gabble alone under extensions/? It wouldn't be so hard to migrate from that to an interface like this in tp-spec if/when it's necessary.
Comment 2 Will Thompson 2011-01-27 10:18:51 UTC
You're missing a flag on Group to say whether SetOwnNickname works, for starters.

I'll have a proper look tomorrow/Monday, and think about whether we can somehow avoid having yet another interface…
Comment 3 Jonny Lamb 2011-02-07 07:37:47 UTC
(In reply to comment #2)
> You're missing a flag on Group to say whether SetOwnNickname works, for
> starters.

Oops, I forgot about this, done now.

Also I added a note about what happens if you set a nickname with bad characters in it.
Comment 4 Will Thompson 2011-02-21 11:32:33 UTC
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Raised when the new nickname contains invalid characters
+            and has been rejected by the server.
+          </tp:docstring>
+        </tp:error>

It can be rejected by either the client or by the server.

For instance, maybe my server supports Unicode 6 while my client only supports Unicode 5, so my client might think that 👀 is not a valid character, even though my server would accept it; or vice-versa.

+          set on the channel, request the user's channel-specific
+          nickname changes. This method is only available in group
+          chats where users can have room-specific nicknames, such as
+          XMPP.

Why is that in SHOUTY CASE? It should be something like “<code>Can_Set_Own_Nickname</code> flag is set in <tp:member-ref>GroupFlags</>”… And the second sentence is kind of redundant with the first. So maybe

“If the <code>Can_Set_Own_Nickname</code> flag is set in <tp:member-ref>GroupFlags</>—on protocols where users can have room-specific nicknames in chatrooms, such as XMPP—request the user's channel-specific nickname changes.”?

+      <p>An interface on connections which is used to specify a
+        default nickname to be used when joining group chats which
+        support channel-specific nicknames.</p>

This is back-to-front. “An interface, implemented on connections where the user can choose a different nickname for themselves in each group chat they join, to specify the user's default nickname in chat rooms.”

+        <p>If this property is empty, the CM MUST use an appropriate
+          nickname when joining channels which support room-specific
+          nicknames.</p>

MUST + woolly terms like “appropriate” seems a weird juxtaposition.

+        <p>Note that changing this property will not affect any
+          currently open room channels which support channel-specific
+          nicknames. To do this, <tp:dbus-ref

Why not?

+        <p>To ensure that all rooms which support channel-specific
+          nicknames have the same nickname, the <tp:dbus-ref
+          namespace="ofdT.Connection.Interface">RoomNickname.DRAFT.DefaultNickname</tp:dbus-ref>
+          property should be changed by calling <tp:dbus-ref
+          namespace="ofdT.Account">UpdateParameters</tp:dbus-ref>.</p>

But you just said that that property doesn't update existing nicknames.

+        <p>Note that if the change is a success then the user's self
+          handle in the channel will change as an existing handle cannot
+          change its meaning. As a result, success is notified by the
+          <tp:member-ref>SelfHandleChanged</tp:member-ref> signal being
+          emitted.</p>

The first sentence needs some punctuation.

It's kind of confusing that this interface refers throughout to “nickname” when it actually means the Group.SelfHandle property. (Which has no Group.SelfID relative, I notice.)
Comment 5 GitLab Migration User 2019-12-03 20:23:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/106.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.