[Suggestion] IRC updates for General IRC clients

I love having twitch piggybacking the IRC protocol for it’s chat especially since even when not watching someone’s stream I can still chat but I’d like to see it improved to be more conformant to the IRC RFC. There’s a few small things that would go a long ways in doing such.

Sending an RPL_ISUPPORT message after the user has successfully logged in containing a network name, case mapping, chan types, and prefix entity would help quite a bit. Without knowing these values, general purpose clients are left to guessing their values and quite often either guess wrong or have some hack-job of a fix that isn’t reliable. Adding RPL_ISUPPORT should not effect clients or bots that can currently connect to TMI as they either can already process the token or will ignore it (as the IRC RFC states a client should for replies they do not understand). An example of what the server should send:

:tmi.twitch.tv 005 user_name NETWORK=twitch.tv CASEMAPPING=ascii CHANTYPES=# PREFIX=(o)@

When a user begins streaming, updates their game, updates their status or stops streaming the topic of the channel should get updated and be batched with the other events(JOIN PART and MODE). When the user first enters a channel the topic should be sent using RPL_TOPIC

:sreject!sreject@sreject.tmi.twitch.tv JOIN #jimsstream
:tmi.twitch.tv 332 sreject #jimsstream :Offline

:sreject!sreject@sreject.tmi.twitch.tv JOIN #samsstream
:tmi.twitch.tv 332 sreject #jimsstream :<status> (Playing: <game>)

Instead of joins, parts, and modes being twitch-client-whatever specific, I’d like to see them togglable via CAP. Many users wish to have the functionality of a specific twitchclient while still receiving such information in an IRC-esq fashion. Currently they either resort to running dual IRC connections or polling the webapi; neither of which are resource efficient for parties involved. My suggestion is move the batched events to a capability - defaulted to NOT sending the batched events - and allowing users/coders to toggle them via CAP REQ:

CAP REQ :twitch.tv/batch-events
CAP REQ :twitch.tv/no-batch-events

When entering a channel, if the connection is to receive batched join, part and mode events it’d be nice if the RPL_NAMREPLY message contained all users in the stream’s channel instead of just the user. This message may have to be broken up into multiple messages depending on its length. Its sort of awkward for people that use the IRC interface for general chatting around twitch to be sitting in a supposedly empty room. The message could be a stale/batched version that’s updated when the joins/parts/modes batch is generated. Along with it user modes should be prefixed to the user’s nicknames. As such this would eliminate the need for twitch servers to send X amount of ‘JOIN’ messages with each ‘batch’ and quite a few ‘MODE’ messages as well, cutting down on bandwidth for both parties and a fair amount of processing that would otherwise be used for JOIN/MODE events. The RPL_NAMES message should be formatted as:

:sreject!sreject@sreject.tmi.twitch.tv JOIN #jimsstream
:tmi.twitch.tv 353 sreject = #jimsstream :@jimsstream @sreject @some_mod someone_not_modded /* ... more users */
:tmi.twitch.tv 353 sreject = #jimsstream :/* ... more users ... */
:tmi.twitch.tv 366 sreject #jimsstream :End of /NAMES list.

As you can see, that would eliminate the need for X amount(equal to number of users in the channel other than myself) of “JOIN” messages + Y amount(equal to number of modded users in the channel) of MODE messages having to be sent to the user.

The IRCv3 client is a nice step but I feel its in the wrong direction. You’ve overlooked those that use the IRC interface for general-purpose chatting. Most clients for such will not know how to interpret the capability if enabled while the users will still want said data. In fact, there’s no seamless way to implement it using mIRC, XChat or HexChat’s built in scripting capabilities; requiring those that are open sourced to be forked, modified then recompiled… Instead, I’d suggest taking advantage of what’s already there: The IRC protocol. With a mix of the RPL_ISUPPORT token and channel-specific user modes it’d be quite easy to indicate to clients who is a site mod, the streamer, mod, sub, and follower. For example, in the RPL_ISUPPORT message you could use PREFIX=(qaohv)~&@%+. This would indicate to clients that the modes q, a, o, h, v (when applied to a channel) effect a specified user:

+q(~): Site Admin or Moderator
+a(&): Streamer
+o(@): Stream Moderator
+h(%): Stream Subscriber
+v(+): Stream Follower

Most general purpose IRC clients will order the users as mode-prefix so the order would be as above. This could be coupled with the above suggest for RPL_NAMREPLY to further conform to the IRC standards. Furthermore as a way to tell clients that a user has been timed out or banned, TMI could take advantage of the standardized +b mode which means banned. Along with these channel-user modes, it’d be nice if twitch also took advantage of modes to inform clients of Subscriber(+m), R9kBeta(+R), and Slow modes(+S). This can be accomplished by sending additional information with the RPL_ISUPPORT message under CHANMODES and then anytime such is enabled/disabled sending a MODE message.

:tmi.twitch.tv 005 user_name NETWORK=Twitch.tv CASEMAPPING=ascii CHANTYPES=# PREFIX=(qaohv)~&@%+ CHANMODES=b,,,mRS
:tmi.twitch.tv MODE #stream +m
:tmi.twitch.tv MODE #stream -m
1 Like

There is a node script built to sit between TMI and the client to offer most of this to the clients that want/need it.

I understand there are projects that attempt to conform TMI more closely to the IRC RFC, as I have wrote my own ‘middleman’ to do the above, but why depend on unsupported 3rd party software when many of the suggestions from my original post should be quite easily implemented with twitch itself?

Personally I’d rather see Twitch spend engineering time on features that would actually benefit the larger user base. These changes would only benefit a very small group. If a developer wants to create an application using TMI then the functionality is already provided or could be provided in better ways (ex: REST API for a channel’s chat status [slow mode values, mods, etc.])

There are 7 (maybe 6) modes you would need to support for users. Otherwise you’d have to use both these and v3 tags to provide this information. (Staff, Admin, Global Mod, Broadcaster, Channel Mod, Subscriber and Turbo)

1 Like

It is simply more efficient to send the relevant metadata in IRCv3 tags than adding the overhead of passing all that data as separate commands. The data is there when it’s needed. The batched data is unreliable (may not be up to date), so the other option would be the same as the old way, sending a chunk of extra commands before each PRIVMSG, which is rather wasteful. IRCv3 data lets Twitch add or remove any metadata from messages without having to create arbitrary commands for metadata and implementing all of these RFC commands, making sure that they comply with the standards etc.

Then, I’d prefer chat as a streaming JSON api anyway. No parser ambiguity, and when WebSocket is implemented, removes a ton of unnecessary work for the web client. But that’s just me.

As some of the other posters here have alluded to, maintaining state is the greatest burden on our chat system. Passing state over IRCv3 tags allows us to greatly simplify the state tracking, and allows us to scale the chat system better. Likewise, batching updates is a necessary measure for scaling the system. Allowing users to disable it is simply not feasible.

You’re right that we’ve diverged from IRC, but most IRC servers don’t have to worry about having 500,000 users in a single channel.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.