Display name client tag spec

[jwheare]

This specification defines a client-only message tag to indicate a display name to use for the attached message, separate from the nickname or realname of the user.

This tag provides a way to provide further temporary context about the originator of a message. Example use cases include bots that relay messages from external contexts, or in role playing environments.

It also describes a fallback for clients without support for the tag.

It does NOT describe a method of servers to spoof the nick in messages, as proposed in #417. I maintain that we shouldn't be suggesting that behaviour. However, servers could easily use the display-name tag as a hint to perform this sort of spoofing if they wanted to.

[progval]

Good spec!

[progval]

So... No > or backtick followed by a space allowed in display names?

[jwheare]

Why not? as long as the stuff in there matches the displayname tag you can still match e.g.
<my> cool> display` name>

[progval]

Oh yes indeed. I didn't think of matching them.

[progval]

Doesn't support /me; which relay bots usually encode as * charles .

I don't see an obvious way to provide a fallback for those.

[progval]

Now I do :)

It should be mentioned explicitly in the spec, so clients can also strip them.

[jwheare]

Thinking about this, I'm not sure it should be in scope for this tag to handle these. Relays usually send /me messages as plain PRIVMSG, so to just get rid of the prefix doesn't really do the right job. You'd have to re-encode as an ACTION CTCP to get the desired effect.

This might be the job for another tag to indicate such messages properly.

[progval]

Another thing: some relay bots add color to the nick (usually only inside the brackets); this should be mentioned too

[DarthGandalf]

I saw colors outside of brackets as well.

[DarthGandalf]

One more idea: I don't know whether it belongs to this spec though. To specify in the message (via a new tag?) whether this display name should be added to tab completion of nicks in the channel. So that it becomes easier to reply to people on the other side

[DarthGandalf]

I also saw bots which insert invisible characters into the nick to avoid highlighting the same person who is both on IRC and elsewhere.

[slingamn]

The collision with "display name" as it appears in the metadata context seems unfortunate?

[jwheare]

How so? It's the same thing, just per message instead of persistent.

[kylef]

Metadata mentions that it is deprecated, given that it discourages its own use and implementation it seems unfit to suggest that as more suitible for some use cases. Would we loose anything if we dropped this last sentence out?

[jwheare]

Yeah it's not ideal. It will hopefully come back in future. I just want to discourage people from just sending a fixed display-name for all their own messages.

[Herringway]

only that specific version of the metadata spec is deprecated, a version fixing the issues that led to that deprecation is still pending

[slingamn]

re. my earlier comment about the name conflicting with metadata, I don't have a clear picture of how this is going to interact with future iterations of the metadata spec. If a relay bot publishes a display name for itself in metadata, but also sends this tag, is the intent that this tag should supersede the value in metadata? But if exactly one field is present, clients will treat them identically?

This capability is unprivileged and allows the client to "silently" change their display name arbitrarily many times on the same connection, which seems like it poses abuse issues that neither RELAYMSG nor metadata did. (RELAYMSG because it was a privileged operation, metadata because of the pub/sub and rate-limiting features.)

[jwheare]

What's the concrete abuse potential?

The intent is that the actual nick is still visible and obvious to users (same as with metadata), which is not the case with RELAYMSG. The display-name is a decoration, not a canonical replacement for the nick.

Since metadata display-name isn't yet defined, it's hard to define the relationship between a metadata and tag-based display-name, but I'd expect a per-message tag could override the metadata version for decoration of messages. That said, clients might want to show the metadata version too, perhaps in a on-click popover or some other paradigm.

I'm not sure how pub/sub or rate limiting has much to do with a client being able to choose their own unprivileged display name.

[slingamn]

I think there are a number of possible scenarios here, but here's one: an unprivileged user can impersonate anyone on the other side of the bridge. If mods are not present and/or the other users are not well-informed about which is the "authorized" relay bot (or if users are not paying close attention to the UI), this could be very disruptive.

[jwheare]

Is that not already the case though? I can change my nick to something similar to the relay bot and then just prefix my messages with <slingamn>

I don’t see how display names makes this any worse.

[slingamn]

It doesn't make it any worse; the claim is that RELAYMSG makes it better.

[jwheare]

It's a non-goal of this proposal to address that.

[progval]

Implemented by Limnoria's built-in relay plugin. It's not the most popular Relay plugin; but the most popular one is third-party.

There's a running instance between #limnoria-bots on freenode Libera.Chat and Oragono's testnet; obviously it doesn't send the tag on the freenode side. It uses color codes all over the <nick@network> prefix/fallback, so it will exercise the receiving clients' ability to filter them out.
For now, @network is part of the display name, because I don't want to make it too hard to detect.
It also sends the display-name on join/part/mode/... messages.

[jwheare]

Message sent on the oratestnet side viewed from the freenode side in IRCCloud (no display-name tag)

Message sent on the freenode side viewed from the oratestnet side in IRCCloud (display-name tag with no prefix removal)

(grey text is realname, tan is nick/display-name, multicolored prefix and black text is message body)

Looks like you're sending the wrong @network as that message was sent on the freenode side. edit: fixed

[syzop]

Sounds fine.

Right now it has no restrictions on the value, though. In my opinion, for security and other reasons it is always good idea to impose at least some restrictions on any parameter/value. Personally I would like to see a restriction on the length and I think we should disallow control chars as well (ASCII < 32).
For comparison, NICKLEN is 30 and REALNAME is 50 in UnrealIRCd. Now, REALNAME is sometimes bigger on other IRCds, but nick name length rarely is much larger on other IRCds, not even on discord (32?) or twitter (15?) etc.
From what I understand this will be used for things like nickname @ network name, so then imagine some rather large nick name length of 48 plus @ network name. 64 could then be a little bit too short. 96 would probably be sufficient?

[jwheare]

Here's a further implementation example that strips the prefix, renders the actual nick specially when the draft/bot tag is present, and uses the display name to choose the nick colour:

[DarthGandalf]

Could the non-normative part describe how to strip the prefix, mentioning various corner cases like colors? The current regexp provided handles very little.

Or, instead, describe how such prefix should be formatted in the message part so that it can be easily removed with such a simple regex?

[jwheare]

I'm going to try reworking the fallback stuff to be a bit more normative, with SHOULDs and mention things like formatting and zwsp anti-highlight bytes.

@syzop I'm not against some sort of value restriction, but not sure exactly what it should be.

[jwheare]

If we disallow control codes, do we disallow the unicode U+007F to U+009F range as well?
https://www.fileformat.info/info/unicode/category/Cc/list.htm (reminder, tag values are utf8)

For reference, these are various byte lengths. All are probably sufficient but I don't want to be too stingy or arbitrary. Clients will after all probably have their own rendering layer limits.

64
jwhearejwhearejwhearejwheare@freenodefreenodefreenodefreenodefre

96
jwhearejwhearejwhearejwhearejwhearejwhearejwheare@freenodefreenodefreenodefreenodefreenodefreeno

128
jwhearejwhearejwhearejwhearejwhearejwhearejwhearejwhearejwheare@freenodefreenodefreenodefreenodefreenodefreenodefreenodefreenode

[Herringway]

I know some people who would use this for roleplaying, and they tend to use colour codes in the names. That's kind of an off-label use though.

[syzop]

Ah okay, I hadn't thought of that. If there is genuine interest in that then we should not disallow all ASCII < 32 in the spec itself indeed. That doesn't mean color and other formatting codes will always make it through, they could still be filtered out, but that is then up to IRCd implementations, server configs and/or channel admins to decide.

My main concern is actually with \r and \n. Those are characters that are not possible in a nick nor even in the content of a PRIVMSG/NOTICE message (nor any oldskool IRC message for that matter). I don't think we should allow multi line display names. Not in the least because they have the potential to take up big amounts of screen space.

As for length, maybe a 005 token like we have for NICKLEN is better, since I have a feeling that IRCd brands and individual IRC networks may make different decisions. You could still mention a minimum or recommended value for it in the specification, though.

[jwheare]

As this is a client tag spec, an 005 token would not be appropriate. We can specify a limit but it would be up to clients to police it at render time. We're talking about a decoration here, not a canonical piece of state carrying data.

In fact if we do specify a limit, it's likely that clients will even enforce a stricter one. So I wonder if it might just make more sense to mention something like "sending clients SHOULD be aware that receiving clients MAY impose limits on the display name" and maybe also "sending clients SHOULD NOT send control codes [to be defined further] in display names"

---

As for colour codes, I think it makes sense to disallow/discourage formatting/colours in the display name itself. I don't plan to support rendering any formatting in our client implementation.

Whether colour codes are used in the fallback string is another matter. It is possible to detect the prefix even with random formatting dotted around it, but it would definitely be a lot easier to strip it out if the spec forbids it.

I don't think it's a great idea to send formatting that will only be seen by clients that don't support this spec. I'd personally welcome not seeing the formatting, but others might miss it ("it worked before!"). Either way the disconnect is odd.

Would that mean certain use cases would prefer not to use the display-name tag at all? Perhaps, but that might not be a big deal. I'd like to see some (clean) examples of how roleplaying like this works at the moment.

Also, @progval did you add the colour formatting to the bot just to exercise prefix removal implementations, or is it something people actually want/use? I've not seen it in the wild, but I don't frequent a lot of relayed channels.

[progval]

Also, @progval did you add the colour formatting to the bot just to exercise prefix removal implementations

No, it's an old thing, that was implemented in Supybot before 2005.

or is it something people actually want/use?

It is. Personally, I really really want relay bots to use color, I visually can't tell who is who without it.

However, I don't care about color in display names, as long as clients colorize them the same way they colorize regular nicks (or in clients like IRCCloud, colorize the pseudo-avatar with the letter)

I've not seen it in the wild, but I don't frequent a lot of relayed channels.

Inventory of relays I'm aware of:

• All well-known Limnoria relay plugins use it by default (Relay, various LinkRelay versions, RelayNext). (Also SkypeRelay, but I wrote it myself so it doesn't count).
• PyLink also uses it in its client bot (I'm not sure it's even possible to disable it)
• Matterbridge supports it, but I'm not sure it's on by default
• I'm in a channel with an XMPP bridge ( based on https://github.com/lrstanley/girc according to its CTCP VERSION), it doesn't have color. It also has an [xmpp] prefix before <nick>
• There's a bot on irc.pine64.org (also based on girc) relaying between various protocols; it has protocol prefixes ([D], [T], ...) and it colors protocol prefix + nick based on the nick

[DarthGandalf]

To add to the list: https://github.com/reactiflux/discord-irc has colors on the inside of <>, as opposed to outside (like Matterbridge does).

I'd personally welcome not seeing the formatting

Please no. It's very hard to see who is talking if there's no any formatting. With regular nicks, many clients do color nicks already themselves, and they can potentically color the display names too. But coloring of the prefix is done by the relay bot, because no client would do such coloring of the <> prefix on their own.

[qaisjp]

Matterbridge supports it, but I'm not sure it's on by default

Matterbridge does not have colors in nicknames on by default.

I do want to say that a number of people like https://github.com/qaisjp/go-discord-irc because it provides an experience most consistent with actual IRC. For regular IRC users, each bridged user will appear in the list of nicks and can be mentioned by way of nick-completion.

These proposals that try to solve the "relaying" problem tend to be only about displaying names and while that provides a great IRC reading experience, it doesn't provide any improvements for IRC writers who want to interact with them (whois, pm, auto-complete names).

I understand that this spec is useful for a variety of use cases, not just relaying/bridging, but please do keep this functionality in mind if you're hoping to optimise the bridging experience. (I suspect other new specs could compliment this spec and provide that better "writing" experience.)

[jwheare]

Thanks for the comments. Fully agree about the scope of this spec, it's by design and isn't trying to solve all bridging issues.

[ValwareIRC]

Not sure how this is getting on to being ratified, but I made a third-party module for unrealircd to allow display-names, and also wrote a simple script for mIRC to allow viewing and sending of display-names

Hope this gets ratified! \o/

Link to mIRC script
Link to UnrealIRCd module