Username sometimes adds a space after the name

[johnpyp]

Very, very rarely I've found that usernames sometimes have a space appended to the end, and it tends to happen on the same user multiple times. Here are the few that I've found in Destiny's chat, out of millions that have been sent in the timeframe:

[johnpyp]

After talking to others about this issue, it seems that: 1) It happens in approximately 0.03% of messages from the past month 2) Messages exhibiting this issue tend to be from a small subset of specific users, it isn't just random. E.g out of 134,349 messages with a space in the username, there were only 3,816 unique usernames. 3) The issue happens with independent parsing as well, so it likely is an issue with the twitch api and not dank-twitch-irc.

Given this, it could be a good idea to add .trim() or something to the username parser to remove extraneous whitespace.

[RAnders00]

This is a twitch thing, they send a space at the end of the display-name tag.

Querying the Twitch Helix API for one of the usernames:

{
  "data": [
    {
      "id": "41174867",
      "login": "itsvinc",
      "display_name": "ItsVinc ",
      "type": "",
      "broadcaster_type": "",
      "description": "",
      "profile_image_url": "https://static-cdn.jtvnw.net/jtv_user_pictures/12fa7203-4acd-40db-8970-84fd1cc781a7-profile_image-300x300.png",
      "offline_image_url": "",
      "view_count": 374
    }
  ]
}

you can see the trailing space after display_name.

[BarryCarlyon]

Copying over for visibility

Start

It's not a bug.

Some users have had a space on their display name for ages for various reasons and can manifest as a \s on IRC/PubSub

Usually indicates a name change back when they were done manually.

The users display name literally has a space on the end.

End

You look up the same user on Kraken, the space is there. It's not a bug, the user literally has a Space on the end of their display name, it's pretty rare

[RAnders00]

Couldn't this be fixed for all users and then all is well? (Remove the space for the affected users)

I think "not a bug" is not a useful attitude here. Nowhere does it say that usernames are intended to have spaces at the end, neither does it say anywhere that trimming them is advisable. This is just one more oddity that literally everybody will have to work around in their implementations.

[BarryCarlyon]

It's not wrong for a space to be at the end of the display name

Consider also

https://api.twitch.tv/helix/users?login=riotgames

username: riotgames display name: Riot Games

or

https://api.twitch.tv/helix/users?login=mister903

username: mister903 display name: 갱생레바

There are many cases where username/login != toLowerCase(display_name);

[johnpyp]

This is an interesting point that I didn't know about, perhaps it should be documented and recommended to use the senderUsername field for accurate/normalized usernames. My implementation has always used the displayName field simply because it was the one prevalent in the documentation examples.

[BarryCarlyon]

You would extract that from the user@host part of the IRC message, like "regular" IRC.

In your OP you are pulling the display_name IRCv3 tag, which by definition is how to display that persons name, it's not the username, as the topic says

Both are two different things.

It's likely overlooked as it's "core"/traditional IRC (I'm talking about Twitch Docs here not this projects)

https://dev.twitch.tv/docs/irc/guide#privmsg

Since you can operate chat with no capabilities and thus tags (and the display name) are optional. If you don't declare

CAP REQ :twitch.tv/tags

before joining any channels, then you won't get any tags at all

https://dev.twitch.tv/docs/irc/tags

Which results in

:<user>!<user>@<user>.tmi.twitch.tv PRIVMSG #<channel> :This is a sample message

Which, for the examples would result in

 riotgames!riotgames@riotgames.tmi.twitch.tv PRVIMSG #channel :a message
 mister903!mister903@mister903.tmi.twitch.tv PRVIMSG #channel :a message
 itsvinc!itsvinc@itsvinc.tmi.twitch.tv PRVIMSG #channel :a message

"Spaces in display names" and "non standard display names" only occur/reported when tags are on.

[RAnders00]

Fixed via e71b53356039a24b3054be330e0a5364f5c97002. New release will follow shortly

[RAnders00]

Fix is now published under version v3.2.0