Giving broadcasters control; concurrent join limits for IRC and EventSub

Announcements
1

As we mentioned in the Standard Output stream before TwitchCon 2023, we are introducing concurrent chat join limits to IRC and EventSub, with broadcaster authorization as a way for your application to scale beyond these limits. To minimize disruption to chat applications, we will reduce the concurrent join limit slowly over the first half of 2024, starting at the end of February.

Why are we making these changes?

We want to provide broadcasters with more control over their chat information and the bots that appear in their chat.

Important Dates

The table below provides the list of dates as we reduce the concurrent channel join limit to 100 on May 15, 2024. Please note that if your chatbot is verified, it is exempt from the limit reductions until we begin a phased exemption removal on May 22, 2024 in order to provide a larger window for updates.

Date Event
February 28, 2024 The concurrent channel join limit is reduced to 100,000.
Excludes verified bots.
March 30, 2024 The concurrent channel join limit is reduced to 10,000.
Excludes verified bots.
April 30, 2024
May 13, 2024		 The concurrent channel join limit is reduced to 1,000.
Excludes verified bots.
May 15, 2024
May 16, 2024		 Concurrent channel join limit reduced to 100.
Excludes verified bots.
May 22, 2024
May 28, 2024		 The verified bot join limit exception for IRC is removed for 4 hours.
Starts at 10am PDT.
June 12, 2024 The verified bot join limit exception for IRC is removed for 24 hours.
Starts at 10am PDT.
June 26, 2024 The verified bot join limit exception is removed.

Who will be impacted by these changes?

Chat applications that rely on one or more chatting users being in chat for more than 100 channels concurrently may need to take action to ensure they have the appropriate authorization from the channel they want to chat in and the user they want to chat as. It’s important to note that users and chatbots active in channels that have the moderator role will NOT count against concurrent channel join limits. If your application or chatbot does not exceed the 100-channel concurrent limit due to having the moderator role, we still encourage you to read further to consider leveraging chat over EventSub.

What actions need to be taken?

With the v1 release of EventSub chat subscription types and the Conduits transport type, There are now three ways your application can read chat in a channel: IRC, EventSub WebSockets, and EventSub Conduits or Webhooks.

Chat access method Requirements for reading chat Ways to scale beyond concurrent join limit
IRC You have a user who is allowed to read chat in a channel. 1. Your chat user is a verified bot.*
2. Your chat user is a moderator in the chat you want to read.
EventSub WebSockets You have the user:read:chat scope from a user who is allowed to read chat in a channel. The authorized user is a moderator in the chat you want to read.
EventSub Webhooks or Conduits You have the user:read:chat and user:bot scopes from the chatting user, and either 1) the channel:bot scope from the broadcaster whose chat you want to read or 2) the authorized chatting user is a moderator in the broadcaster’s chat. There is no limit to the number of channels you can read chat in with this approach.

*This is a temporary way to exceed the join limit, meant to enable large bots to update without disruption as we reduce concurrent join limits. We will remove this exception after we’ve reduced the concurrent join limit to 100 channels on May 15, 2024. Please refer to the table of dates above for when verified bots will be affected.

If your chat application needs to join more than 100 channels concurrently, we recommend updating to use EventSub with the new Conduit transport type. Here are our recommendations for common scenarios:

Non-moderation chatbots that are in more than 100 channels concurrently

Migrate your application to EventSub Webhooks or Conduits. Begin gathering the required channel:bot scope from the channels where your bot operates today.

Cloud chatbots

We recommend migrating to EventSub Conduits to enjoy higher uptime in channels and to leverage future Twitch Chat features as they become available to third-party developers via EventSub. However, if your bot is used for moderation and has the moderator role in the channels where it operates, it may not be affected by the concurrent join limit and can continue to connect to those channels via IRC.

Installed chatbots

If each client of the chatbot uses a different chatting user, it is possible that your bot would not reach the 100 channel concurrent limit and could continue to use IRC unaffected. You could also migrate your application to EventSub WebSockets. We recommend migrating to EventSub WebSockets to leverage future Twitch Chat features as they become available to third-party developers via EventSub.

Chat clients

Each chatting user has their own concurrent join limit, and those with moderator status in a channel can join that channel without it counting toward their limit. So it is possible that the concurrent join limits will not affect users of your application. We recommend migrating to EventSub WebSockets to leverage future Twitch Chat features as they become available to third-party developers via EventSub.

I still have questions

Please feel free to use the comment section below for any questions you have regarding this upcoming change to join limits. We also plan to send email communication to potentially affected developers and you are welcome to reply to that email message as well.

3 Likes
2

Currently, IRC allows anonymous connections.
Is there a plan on how to go about that, in the future?

1 Like
3

This is great news. Finally those pesky lurk bots get killed of, slowly but surely

7 Likes
4

What about the message limits? Will they stay the same (Especially for verified bots/non-verified bots)?

2 Likes
5

My bot is old school, providing all management operations solely through IRC chat, incuding join/part. I have a super simple website that can get tokens for the things that have already been locked off, but not all people who use my bot have actually logged in.

Is it correct to say that I can get a token on my own bot account with user:read:chat and user:bot (not the channel) and still be able to have the bot behave the same way?

Otherwise, the effect of this change will be requiring every user to auth again to be able to read their chat, so everyone will just… lose the bot until they realize that it’s not moderating or replying to commands (if they haven’t granted it moderator perms).

6

if your bot is a mod in the destination channels: yes
if your bot is not a mod in the destination channels: no

Exactly, this will happen anyway if/when Twitch adds new API’s that need new permissions anyway depending what your bot does.

7

It seems like the main post was edited from:

to

So, I guess the gist is that there is no method by which any bot owner can be in more than 100 channels unless the broadcaster has OAuth’d into a bot, or granted that bot moderator permission.

At least my bot is “verified” so I have a little more time than most, but this means I’ll have to totally redo the way my bot ingests messages (since IRC is no longer sufficient), and attempt to get everyone to reauth to gain scopes. Not that I have much hope… a large number of users still have not reauthed since moderation commands were removed from IRC. That or I just remove the ability for the bot to be in any channel as a non-moderator. :frowning:

Regardless of any other new Twitch features I may or may not want to use, chat is still the core feature that any bot needs.

8

How does this affect anonymous usage? I know some tools that use a fixed username (e.q. justinfan123) for their tools. The tool itself just joins one channel but several people use it with different channels. So does this limit count for all connections or just for each one?

9

Those tools would logically use an implict oAuth token and connect and read chat as the streamer over eventsub websockets. (In my opinion)

10

Hey! If we have a bot with the npm dependency with the following options:

const options = {
options: {
debug: false
},
connection: {
reconnect: true
},
channels: [this.channel]
};
this.client = new tmi.client(options);

To track all the chatrooms chats (not verified) only read not write, will this change make any effect to us?

11

yes

12

Is this limit per Connection or per User?

13

As Ways to scale beyond concurrent join limit in the OP is listed, the way to scale for IRC is a verified bot (for the time being), or be a mod in the channel you’re joining. Extra connections is not listed as something that would in any way help circumvent the limit (and it’d be a pretty pointless limit if it could be so easily bypassed just with more connections).

I’d expect it to be a limit per user/Client ID, so that one 3rd party app wouldn’t impact another 3rd party app, or the first party site, but that does need clarification.

14

Per user. :wink:

15

I applaud these changes!

However, if someone does the above, and makes tons of account, it’ll be harder to track and ban lurker bots, so broadcasters who want to ban all lurker bots might be in a worse position than they are now, with less control over the situation.

Or, am I missing something?

Edit: Oh, wait, you’re locking down privileges, too, so anyone connecting to a chat would have to have chat:read auth for that channel? That would probably suffice. Sorry, coffee hasn’t hit yet. Still wrapping my head around this.

16

But how is this going to affect us? Will we need to login to use it? And therefore we will be capped to 100 chats per user?
If so, on the web you will not be able to see the chat if you are not logged in?

If not, that is to say that we will still be able to use the tmi.client without credentials, I understand that you are going to assign a token (or an internal id) for each anonymous user and that will help you to know how many chats at a time we are watching, right? Or it will be by IP or how?

Sorry, I know it’s a lot of questions but we have to adapt to these changes as soon as possible :slight_smile:

17

It’s not yet known how this will impact justinfan connections, so to prepare I would suggest your app gets the required scopes from broadcasters to connect to chat as a bot, as it could very well be the case that you wont be able to connect to more than 100 channels using justinfan.

Justinfan was never officially documented, so you may not get a specific answer on how Twitch will limit these types of connections to prevent abuse and people trying to circumvent the limits. If your goal is to track all of Twitch chat anonymously then hopefully these change would prevent such use, as already Twitch have shut down the official means of doing so that Twitch supported, Firehose.

18

From your OP I assumed you were logging in as a user to Read anyway.

What is your use case for scraping chats? Why do you need to connect to all chats? Thats not a normal use case

19

Hey everyone! Nowadays I’m reading the chats of the top 500 twitch channels like this:

class Client {
constructor(channel) {
this.channel = channel;
this.connected = false;
const options = {
options: {
debug: false,
},
connection: {
reconnect: true,
},
channels: [this.channel],
};

	const onChat = (channel, user, message) => {
		<function>
	};

	this.client = new tmi.client(options);

	const events = [
		'ping-timeout',
		'hosting',
		'raided',
		'resub',
		'subgift',
		'subscription',
		'animate',
		'chat',
		'action', 'ban', 'ban', 'ban', 'ban', 'ban', 'ban
		'ban',
		'timeout',
		'reconnect',
		'disconnected',
	];
	events.forEach((event) =>
		this.client.on(event, (...args) => {
			if (event === 'chat' || event === 'action') {
				onChat(...args);
			}
		}),
	);

	this.client
		.connect()
		.then(() => {
			message_counts[channel] = 0;
		})
		.catch((err) => {
			if (
				streamers[this.channel] &&
				!streamersToConnect.includes(this.channel)
			) {
				this.client.removeAllListeners();
				streamersToConnect.push(this.channel);
				++timeouts;
			}
		});
}

}

As I am creating a client for each channel there should be no problem to connect to the first 1000 no? I understand that what you are going to reduce is the number of channels to which we can connect from the same client, right?

For example, if I did like this:
class Client {
constructor(channels) {
this.channels = channels;
this.connected = false;
const options = {
options: {
debug: false,
},
connection: {
reconnect: true,
},
channels: this.channels,
};

Being channels an array of 500 channels. Then I would have a problem isnt it?

Thx!

20

Yes as the eventual max is 100