Is there going to be a way to request higher API ratelimits, now that we’re being forced to migrate calls to Helix? Going from verified bot IRC ratelimits to something significantly smaller certainly is going to hurt.
Open up the get moderators and get VIPs endpoints to not require a broadcaster token. It’s a little ridiculous to need a broadcaster token to get that info, when any registered user can simply type /mods or /vips in Twitch chat.
I get why most of these changes are coming, I had a feeling as soon as the moderation endpoints were rolling out. But we need to be able to request higher rate limits now since you’re pushing us all to use Helix. Forcing Helix usage without rate limit adjustments is a step back in functionality. Sure, I can get around it by using the broadcaster’s token to perform certain actions, but I shouldn’t have to.
The API currently only supports doing timeouts as the access token’s user. So when you’re using the broadcaster’s token to timeout, the users in chat and the chat logs see the timeout as coming from the brodcaster (and not the app’s account) Using an app token is not viable here because the singular app token rate limit doesn’t scale with timeouts unfortunately.
Is this an issue that can be resolved somehow?
E.g. if it’s a broadcaster’s token, the “moderator_id” can be set to the user-id of the account the client-id belongs to (without the access token necessarily coming from that account)
That’s the problem. You’ll then be limited by that singular rate limit (the bot’s token) across all the channels that you moderate.
The point of using user tokens is that each “channel” has its own token, and thus its own rate limit. So channel A doesn’t use the rate limit of channel B.
It was unclear to me that was the problem. (And missed in my initial thoughts)
But I feel the helix rate limit might be sufficent, since the mystery ban limit is per channel.
So I think the intent is you can wack as quickly via the API as you can via chat. But this might need the older IRC command proxies to die to clear out engineering resources first.
Any Twitch account that already had verified bot status will continue to have the higher Whisper limit of 20 per second, up to 1200 per minute, for 100,000 accounts per day.
So that will be going away…
I find it interesting that it’s not too difficult to have rate limits based on account type and even when the account got that status, but it’s too difficult to not make developers jump through hoops just so things continue working, albeit with higher bandwidth requirements and additional latency.
It makes me think of a Steve Ballmer quote preceded with one of his favorite words.
(Generally) Any endpoint that uses a scope starting moderator: will work with the bots own token. (as long as the bot/user authed as is a moderator in the channel you wish to take actions on.
This covers all commands exceptcommercial, Get Mods and Get VIPS. Which yes as you note requires a broadcasters token.
And a bot can still obtain moderator (or VIP) status by interrogating the tags on a recieved PRIVMSG
So, one command was missing from the API, and instead of just adding it and supporting both you rip out all the other IRC commands that were working fine. That makes a whole lot of sense. Kappa
Come February, will we get rolling sunset windows where the IRC commands are disabled so that folks who don’t see this announcement will notice something is wrong (and have some time to migrate before an abrupt shutoff)?
After removing chat-specific commands from chat, what’s next?
JOIN/PARTs are already not reliable. We’re still waiting for the promised improvements. Maybe ripping all of the chat commands out of chat will fix it?
There is an endpoint to send chat messages, so why not force all the messages to be sent through that? And keep its 12 messages per minute limit, if we’re ignoring previous limits anyway.
It’s been requested for a while to have a public endpoint to get recent chat messages. If you add that, then you can remove tmi entirely. That will resolve the “unfortunate segmentation of functionality” and is consistent with the “effort to group all actions under the Twitch API”. That could be an “improvement to Twitch Chat”.
“[S]ome actions that you would typically leverage via an API” and definitely not from within chat itself include: announcements to chat, bans from chat, clearing chat, deleting messages from chat, options for controlling who can chat and how, as well as determining which users have special privileges in chat, and other ways to chat.
It’s clearly best to have commands related to chat not be available from within chat. Of course they “will still be available within Twitch-owned chat interfaces such as a channel page on twitch.tv or in the mobile apps”, “but third-party developers must” do extra work.
You do realise that chat commands on the website don’t go out via the chat socket anyway.
So this change brings chat commands for developers in line with how chat commands operate on the website.
For end users there is no visible difference, since end users already have “API Chat commands”
Case in point: the new announcment command.
IRC/Socket users only got the default announcment color. /announcepurple wasn’t made available to socket users. This is API only. And when all chat commands are API only it’s a level playing field for Website/Socket. And easier for Twitch to Develop if they don’t have to consider API support and socket support. (which was ignored for /announce)
A follow-up question regarding the limits of “bot” user tokens for “moderation” tasks.
Will the request be in the same total “bucket” limit as the regular API or will they be unique per “broadcaster_id”. Thinking specifically for all API endpoints based on the scopes: “moderator:manage:*” and “moderator:read:*”.
If they are actually under separate buckets of the rate limits, it would be nice to get some clarifications regarding this, or at least some information what is planned to happen. Because if the user token will be limited by the global limit for those actions, there are going to be a lot of troubles in handling larger amounts of channels, when a lot of automated moderation is wanted.
Your app is given a bucket for app access requests and a bucket for user access requests. For requests that specify a user access token, the limits are applied per client ID per user per minute.
If an endpoint uses a non-default points value, or specifies different limit values, the endpoint’s documentation identifies the differences.
PS: Yes, I have seen that Barry made a comment regarding some “Magical” limit per channel previously as a vague answer:
But I feel the helix rate limit might be sufficient, since the mystery ban limit is per channel.
EDIT: Did some testing after posting this, and tried to ban several people in the same or different channels with a user token. The headers responded back do not seem to reflect the correct values as expected, it continuously says “remaining: 799” at all times.
As it’s written, the bucket used will be the user bucket of the moderator user whose token is used to do the action. In other words, in a typical case where your bot uses a single user account, all moderation actions count against the same limit, regardless of channel/broadcaster_id. If you use the broadcaster’s token instead, then the limit will be effectively per-channel, but someone mentioned it will appear to be done by the broadcaster him/herself, which may be undesirable.
Sure that is a solution, but as described above… this adds another issue. If the user changes password etc, the token will be killed and they have to “re-sync”.
Instead of having a single bot account, the developer instead needs to maintain it. But also add new scopes as the twitch API continues being developed over time. So for me, this is a no go solution with using the “broadcaster” token.
The global helix rate limit for the client_id-user_id pair: 800 points, 600/60s refill
Channel-specific bans bucket: 100/30s per channel (unofficial & likely per mod_id)
For “Ban User”, the remaining header is not particularly meaningful, as it reflects the former (global limit) rather than the latter (ban-specific bucket)
I do agree that all these IRC->Helix changes should be accompanied by more clear & explicit documentation for these endpoint-specific rate limits
