Update: We will eventually remove the NAMES functionality as planned due to its unreliability. However, given the usage discussed below, we will postpone the removal until there is replacement functionality. This post will be updated when it is available and a timeline has been set for a migration and shutdown of NAMES.
The MODE and NAMES IRC capabilities that have been documented in the Chatbots & IRC section have not functioned correctly for some time and will not be supported. Since we do not want to offer incomplete or inaccurate functionality, these capabilities will be removed from the IRC interface on June 15, 2020TBD.
Whatâs changing?
As of today, we are updating the documentation to remove mention of these capabilities. On June 15, these capabilities will be removed from the IRC interface.
Who will be impacted by these changes?
Developers who are (1) using MODE to understand who is a moderator for a given channel or (2) attempting to use NAMES to list the Twitch users on a given channel.
What action needs to be taken?
If you are using MODE for moderator information, it is recommended to use the Get Moderators API endpoint to get the current moderators list for a channel and subscribe to the Moderator Change Events webhook for real-time moderator changes.
NAMES, as mentioned in the documentation, could not support user lists over 1000 and has not functioned properly. It is recommended to remove use of this capability before the date above to avoid any errors in your applications. There is currently no supported method to retrieve the list of Twitch users present on a given channel.
The Get Moderators API is behind a scope. This means I need the broadcasters permission (via OAuth) to see if I myself am a mod in their channel. Or am I missing something?
Thanks! I totally forgot about the âUSERSTATEâ message. I also remembered that I can just use /mods and parse the result. This wouldnât be visible to others and wouldnât need any OAuth.
I can understand it, but it has worked quite well for smaller channels.
I want to bring the following points into consideration:
As people inevitably want to still implement things the way they have been, if this change doesnât remove a certain undocumented endpoint, traffic to it will drastically increase, which comes itself with issues - but then again, it is an undocumented endpoint, so people must not complain what happens with it. If it gets removed, a potentially official replacement Endpoint would be really handy. nudge nudge wink wink
If people change implementations, it will end up meaning lurkers will have to end up being âless appreciatedâ because whatever integration may have been set up to deliver features that includes lurkers wonât be able to fetch them anymore.
If 2) holds true, it may encourage people to spam more in chat when they are aware that their viewership only counts when they are posting something in chat. Noone likes spam.
With the last change, a rolling window deployment was used and it was met with overall amazingly positive feedback. It would be VERY beneficial if such procedure was done for this change as well. If not, it would be great if some notice was sent in lieu of the ânormalâ NAMES response so devs know whatâs up.
Itâs very understandable (in my opinion) that you donât want incomplete/inconsistent functionality. Iâm increasingly curious as to why the list behaves as it currently still does. Could we get some insight into it? Itâs probably interesting.
Disclaimer: This is mostly my opinion and the direct impact i see for my application. Feel free to share other opinions!
The membership capability is still documented, with JOIN and PART. Does this mean that joins/parts from other users in the channel are still going to be sent by the server, just not the initial full userlist? Otherwise Iâm not sure what the point of the membership capability is, since of course a JOIN/PART for yourself when joining/leaving a channel is sent by the server either way.
Hey, eng manager for the Chat team here. Thanks for the early feedback.
@tduva
The JOIN/PART IRC messages are not intended to go away with this change. These, to the best of our knowledge, are working as intended today.
MODE and NAMES are messages in a less understood part of the codebase that werenât largely used by the developer community. They werenât used by our first party apps, and there was additional maintenance overhead to test and maintain it as features/code changed around them.
The Chatters List is a product weâve had a lot of internal discussion around. I canât promise any timelines, but more official support for the functionality is on our radar.
There are tens of thousands of streamers that use loyalty points features that are going to be impacted with the removal of NAMES. NAMES was working reasonably well for smaller channels (< 1000 users) which does represent a fairly large community.
So removing NAMES without an alternative is going to hurt a very large streamer base and getting the list of chatters is at the core of most loyalty platforms that streamers build their engagement model around. I would urge you to reconsider leaving this in its âbrokenâ state until an alternative could be offered for this use case.
Please donât remove NAMES (until /chatters is officially documented and supported)
Itâs critical for my bot to accurately measure viewer engagement and reward loyalty points. My entire channel concept is built around viewers accruing loyalty currency to spend on voting for the next game I will play. I have a small community, and most of my viewers are loyal enough to stay in chat all the time. With this change, my bot wonât be able to know they have been there the entire time, so it will punish my most loyal lurking viewers. If some more-accurate replacement for NAMES can be rolled out, that would be acceptable, but please donât remove it while there is no workaround for bots in place!
I would much rather see this left in its current state until a replacement can be offered that creators can merge to. Upright removing it doesnât seem like a logical path.Thereâs thousands of bots dependant on NAMES and MODE. This will also punish lurkers and collapse a lot of communities.
I have created a bot according to the Twitch API documentation, which uses the NAMES capability and while Iâm able to use the JOIN and PART messages to get a general idea on who is in my channel, the NAMES capability is essential if someone happens to be in my channel prior to my stream starting or if my bot crashes or needs to be restarted while Iâm streaming. I would welcome a replacement for the NAMES capability in order to get a list of users in the channel.
Takeaway: Sunsetting NAMES should be fine for bots provided Twitch is able to document and officially support the /chatters endpoint before it is removed. Maybe this would work as a compromise?
I was going to avoid mentioning that endpoint as itâs undocumented and can be changed/removed without notice. But your request of making it supported is a good idea. - Maybe add it to helix?
Hi everyone, thank you for providing the above feedback and use case for the NAMES capability. We will eventually remove the NAMES functionality as planned due to its unreliability. However, given the usage discussed above, we will postpone the removal until there is a replacement, such as the Helix endpoint mentioned above.
At this time, we consider NAMES deprecated and would like to reiterate we do not intend to fix this capability. Docs will be updated accordingly. This post will be updated when a reliable alternative is available and a timeline has been set for a migration and shutdown of NAMES.