Notice of upcoming changes: deprecating the TWITCHCLIENT command

Hey everyone,

I wanted to give you all a heads up that next week we’ll be officially deprecating the TWITCHCLIENT command in favor of our IRC v3 commands (documentation here, including recent capabilities we’ve added which keep non-TWITCHCLIENT users at feature parity going forward).

We’ll continue to support TWITCHCLIENT in the short-term, though we plan on making some backend changes which make TWITCHCLIENT features less robust (such as guaranteed ordering of USERCOLOR before PRIVMSG).

Once we know an exact date that we’ll stop supporting TWITCHCLIENT we’ll give several weeks of advance notice.



Thanks for the information. Thanks for adding the membership capability as well. Makes much more sense than having to maintain a secondary connection just for the userlist.

I noticed some messages don’t work yet unless I use TC4, for example a HOSTTARGET on join or when I enable/disable slowmode or submode. I assume this is still going to be added in some way (maybe also a CHANNELSTATE message or something).

Many messages that require TWITCHCLIENT currently (like slow-mode, etc) will get a replacement before TWITCHCLIENT is officially deprecated. It is likely to be replaced by a enabled NOTICE message. When it is finalized, we’ll update this thread.


Is it easier if we report issues with the documentation and implementation here, or if we report them as github issues on the chat repo?

If there are discrepancies between the description of the API and how the system currently behaves, please report them as github issues.

1 Like

Would it be possible to add a CAP for followers? I have a feeling that might make follower notifications way easier, cheaper both on twitchs and on the clients side, and have them be instant, instead of delayed by whatever the checking interval is.
I would imagine it would be something along the lines of jtv sending info messages about who followed (perhaps even accumulated over a couple of seconds)

Especially when paired with the new websockets, this could make alot of things easier.

Alright, thanks. I filed a ticket for a small spec violation issue that I found.

FYI we will soon be migrating various “jtv admin” messages to NOTICE commands (which will also help us with chat localization) - for instance toggling subsonly mode will look like this:

@msg-id=slow_off NOTICE #twitch_user :This room is no longer in slow mode.

This will solve one issue with non-TWITCHCLIENT clients missing various messages.


Sounds great. Will this also be send on join? Would be useful to display the state.

We do have plans to expose the chat state on joining a room, but that will be a later change.

We’ve started this transition, and we’ll be changing more admin-type messages to use NOTICE in the coming days as well. We’re planning on removing TWITCHCLIENT support in 2 weeks (on Monday, June 15).

1 Like

Will the NOTICE changes be something we subscribe to, or will it all just turn on at a random time one of these days for every client?

And does “changing more” mean you’ll be changing some one day, and some other at a later time?

Keep in mind with the join restrictions it takes like half a day just to rejoin all chats after a patch.

You will receive NOTICE commands by requesting the commands capability. We’re planning to roll over existing jtv messages into NOTICE messages in one group just prior to removing TWITCHCLIENT.

I’ve updated our documentation to include NOTICE and GLOBALUSERSTATE commands.

I also forgot to mention previously that CLEARCHAT and HOSTTARGET messages are no longer sent as “jtv” admin messages, and only as commands (including TWITCHCLIENT users).

1 Like

it would be nice to have all possible values of NOTICE’s msg-id in the documentation as well.

1 Like

Done, the documentation now includes a list of msg id values and their associated text

How are subscriptions going to be announced?

Should be from twitchnotify like usual unless otherwise stated, though sending notices for them instead is not off the table

How will GLOBALUSERSTATE work? Will it be the same as USERSTATE (for local user only, same tags), just with no channel?

Edit: I noticed it’s already being sent:

@color=#9ACD32;display-name=tduvaTest;emote-sets=0;emotesets=0;turbo=0;user-type=;user_type= GLOBALUSERSTATE

Hmm, PRIVMSG tags don’t seem to have emote-sets, and I’m not quite sure how USERSTATE messages are actually sent. I have all 3 caps enabled, yet I only get a single USERSTATE line when I first connect and nothing afterwards.

Can’t find anything more about this in the documentation, could anyone expand on how to get emoteset info?