IRC v3 - the future?

We hope to leverage IRC v3 for an improved chat protocol, particularly utilizing message-tags ( which allows us to attach metadata to specific messages.

IRC v3 is backwards compatible, so unless you explicitly register a capability (, indicating you can handle message-tags), you will not receive the tags (and messages remain the same). Keep in mind that we plan to deprecate the existing protocols (aka TWITCHCLIENT), but have no ETA when old protocol versions will no longer be supported. Rest assured that we’ll give you plenty of warning (months? years?) before we remove support, so we don’t believe there is any cause for alarm.

Also keep in mind that the IRC v3 message-tag spec expects clients to ignore tags that they aren’t familiar with. This allows us to add new features/tags to our messages without worrying about clients breaking.

As an example of a message with tags to give you something concrete, although the actual protocol hasn’t been determined, it may look like this:

@chansub;turbo;mod;some_key=value;key2=value2 :user! PRIVMSG #some_room :hello there



I like the idea. This gives the meta information ‘message level’ scope which could open up a lot of possibilities (e.g. options to enable hosted streams chats to be merged.

On the topic of chat protocols, are there any plans to adopt the private message protocol to be able to send messages specifically to individual users? This would greatly help streamers keep chat clean by removing a lot of the text based input/output from public chat.

Sounds good in general. Having the info in the same message instead of before every message seems to make more sense. Especially with how it is currently where you don’t really know what you get from the jtv user, whether it’s a command or an actual message to be displayed (except that the first word is all uppercase). An actual well-defined protocol sounds more stable.

How are you going to handle joins/parts/userlist which probably doesn’t get send to the webclient but may be wanted by others? Also you have “mod” in the example, will the +o modes still be there then? Not that special clients really need them (they can use the tags), but regular IRC clients might. (You probably don’t necessarily know at this time, but just bringing it up.)

JOIN/PART support will be a separate discussion. There will be a thread some time in the future to discuss our thoughts on how to support this feature without it impacting chat for regular users. I don’t want to derail this thread with that discussion though.

Don’t want to derail this thread, but currently we have no plans to support it. We actually do have the infrastructure to send messages to individual users (and it is used for some features), but we’re pretty sure our server cannot scale to the usage if we made the feature available to everyone. Supporting it would be a pretty big project, and we already have a lot on our plate to make the current features work.

Yes, there are no plans to get rid of +o modes so that IRC clients still have useful information. However, there is a delay regarding when a user joins and when other users are notified (and given their +o privileges), and we want to make sure that if a moderator sends a message, users will always see their mod badge, at least on official clients.

1 Like

why removing something does works good? Do you wanna kill exsistings app? Also why twitch removed all good API from JUSTIN TV? Like country or bitrate. Just add, dont remove good things.

Nothing is being removed from IRC, only improved. Read the first post more carefully.

Where do you see anything about them trying to kill existing apps? If you read other posts on here, you can see Twitch developers are trying to help existing apps.

JTV was a cancer that had to be removed for Twitch to move forward. Tons of security issues over there, maybe just happening due to its age. There was also blatant piracy going on in their entertainment section (Family Guy, Simpsons, Movies, etc.), which is a liability waiting to happen. Twitch’s infrastructure was also being held back by JTV, as both sites shared the same databases on two completely different sites. JTV was Python+Django and Twitch is RoR.

While there’s missing things from the Twitch API, they may just not be possible due to performance issues. For example, Twitch won’t add the ability to check if a channel has a sub button because it’s too resource intensive for them to pull that at scale.

I’m definitely excited for this, just thinking about all the cool new things you’ll be able to do

@night thanks for info.

I really can’t wait for this.

For the emotes.
I seen that emotes will now be parsed server side, how is it going to get passed to the client? Will there just be the “emotes” separated by a token delimiter or will it just be a concise /chat/emoticons json string?

Where did I say this? In any case, yes, we are moving to parsing emoticons on the server because the number of emoticons is growing too quickly. Requiring clients to be aware of all emoticons is a burden on clients, especially given that a very small subset of emoticons are used in a typical user’s session.

The format is mostly defined internally at Twitch, but is subject to change, so we will not publish it yet. I will add that both the emoticon parsing and the IRCv3 changes are being QA’d as I type this. You can expect a release in the next 2 weeks.

Will be affected by change? A lot of non-chat related applications do utilize it.

1 Like

That API will not be changed.


Before you start work on bigger things like Message Tags, it would be nice to see at least a basic 005 numeric with NETWORK and PREFIX tokens.

Also sending op-status with the NAMES reply when users join, instead of having the jtv bot send several lines of mode changes.

If you want a more real IRC experience, you can check out a simple relay service I made Twitch’s IRC isn’t really irc (it lacks a lot of RFC commands, including WHO), so while it may share some of the formatting it really is a beast of its own. I’d much rather Twitch devote time to adding things like message tags and fixing rate limiting.