Deprecation of chat commands through IRC

[BarryCarlyon]

@felanbird

How will this effect replies?

it doesn’t as /reply isn’t quite a command when a bot does it anyway

Reply is a PRIVMSG tag not a command

For example:

socket.send(@reply-parent-msg-id=${id} PRIVMSG ${room} :${message});

[zikaeroh]

@BarryCarlyon

All of these are on the bot account. As banning/timeing out needs a token from a moderator or above. So you just need to refresh the bot’s token

I’m not sure what you mean; this isn’t the old channel_editor scope which allows a bot account to operate on a channel (of course, that only worked over IRC tokens too). When I ask the user for permission to do something to their channel, OAuth gives me back a token that is specific to that user, and I need to provide that token to the API when doing something on their channel. I can’t use the bot’s account for this, because there’s nothing linking the bot’s token to any sort of granted permission to any one channel.

See all of the docs that say things like “This ID must match the user ID associated with the user OAuth token.”

[felanbird]

I am aware, I’m just making sure there isn’t some form of oversight when the eventually fully deprecate sending messages from IRC.

[BarryCarlyon]

@zikaeroh

I’m not sure what you mean; this isn’t the old channel_editor scope which allows a bot account to operate on a channel.

No channel_editor is for /raid and /host. And if the bot account is an editor on the channel.

Host is no more. And raids have an API which requires the broadcasters token sure. But thats only if people are using your bot to initiate raids in the first place.

@zikaeroh

I can’t use the bot’s account for this, because there’s nothing linking the bot’s token to any sort of granted permission to any one channel.

If the bot is a moderator in the channel, then the bot can time people out.

@zikaeroh

See all of the docs that say things like “This ID must match the user ID associated with the user OAuth token.”

Any endpoint that uses a scope starting moderator: will work with a moderators token, if the user ID in the oAuth token matches the moderator_id specified in the Payload

(Some of the documentation has some copy/pasta with that text in error leading to a lack of clarity)

So for example

The user cohhilitionbot is a mod in cohhcarnage
I will upgrade the token for cohhilitionbot and then call the API authenticating as cohhilitionbot with cohhilitionbot token.

[zikaeroh]

No channel_editor is for /raid and /host . And if the bot account is an editor on the channel.

I was just using that scope as an example of one that allowed things to happen when using a token that wasn’t the end-user’s; I do know how it works.

Any endpoint that uses a scope starting moderator: will work with a moderators token, if the user ID in the oAuth token matches the moderator_id specified in the Payload

Thanks, this is the key info I was missing. The last I read the APIs, they didn’t accept moderator_id.

[BarryCarlyon]

@zikaeroh

I was just using that scope as an example of one that allowed things to happen when using a token that wasn’t the end-user’s;

channel_editor is also a deprecated “v3 style scope” so it’s basically dead anyway. shrugs

[Gatt]

I’m moreso wanting reasoning specifically removing these things via IRC. If the bot account is marked as a moderator on a channel- does it really matter?? They’ve been specifically given access to moderation features within that streamers channel. I understand the decommissioning of old systems (Twitch decommissions their APIs frequently…), however I cannot see any benefit to removing these things from the IRC chat connection. That’s moreso what I’m wanting an explanation of (ie; benefits, future usages, future changes, etc)

[zikaeroh]

Indeed, it never really worked in chat correctly anyway.

[TheElm]

You can see here in the docs on issuing timeouts

The request must include:

• A user access token that includes the moderator:manage:banned_users scope.
• The broadcaster_id query parameter that’s set to the ID of the broadcaster that owns the chat room.
• The moderator_id query parameter that’s set to the ID of a user that moderates the broadcaster’s chat room or the broadcaster’s ID. This ID must match the user ID in the user access token.

You can see in the last bullet point that “moderator_id” (The moderator account) is the one that matches the provided oauth, so as long as your account is a mod in the channel, you can issue timeouts and bans.

[BarryCarlyon]

@Gatt

I understand the decommissioning of old systems (Twitch decommissions their APIs frequently…), however I cannot see any benefit to removing these things from the IRC chat connection. That’s moreso what I’m wanting an explanation of.

Probably older services in the background that need to be removed.

And have been (since running commands via the front end do not go via chat) already.

So it’s just the older IRC system using the older services that are showing their age.

Thats my theory.

[Gatt]

Breaking this out into a separate comment since it’s a separate thing;

How will this affect external chat programs such as Chatty. As far as I understand- they’re just IRC clients (unless I’m mistaken).

[BarryCarlyon]

@Gatt

How will this affect external chat programs such as Chatty. As far as I understand- they’re just IRC clients (unless I’m mistaken).

Chatty will need to update to use the API.

They already have a moderators token (or a token to login to chat with). So just funnel commands via the API instead of the WebSocket. (And upgrade the login step to request the needed scopes).

Chatty and other third party chat clients just need to update.

It’s basically the same “upgrade” requirements as upgrading a channel bot.

[zikaeroh]

Chatty uses the API when it needs to. I guess it’ll need to use it even more now.

[TheElm]

@Gatt

How will this affect external chat programs such as Chatty. As far as I understand- they’re just IRC clients (unless I’m mistaken).

Yes chatty uses IRC to read messages, it’s the only way for third parties to read chat live. But Chatty is a custom app that adds its’ own implementation to support Twitch. So it’ll have to update to support this change, but it’s not going to kill Chatty.

You’d have more difficulty if you were using a plain IRC client like HexChat, which is strictly IRC.

For example Chatty displays Twitch Emotes by fetching them from the CDN, this isn’t something that HexChat (Plain IRC) would do.

[matwalsh]

(I don’t see /r9kbeta noted on any of the docs pages; I guess that’s been renamed to “unique chat” mode at some point?)

The r9kbeta/off command exist but the unique chat commands are preferred - from the 2022-02-11 changelog note at Changelog | Twitch Developers

Replaced the /r9kbeta and /r9kbetaoff Twitch chat commands to /uniquechat and /uniquechatoff, respectively, to match the commands used in Twitch Chat. The /r9kbeta and /r9kbetaoff continue to work but you should start using /uniquechat and /uniquechatoff at your earliest convenience.

[ImStillJohnny]

A lot of the comments so far have been negative, so I just wanted to chime in that I like this change, and I can see how this opens up future possibilities. Plus I’m sure using the API allows Twitch to process things in ways that doing it via IRC does not.
Keep up the good work!

[prod]

@jbulava

and in the process allow further improvements to Twitch Chat

@BarryCarlyon

So I imagine around february more improvements are planned once old services can be decommissioned.

@ImStillJohnny

A lot of the comments so far have been negative, so I just wanted to chime in that I like this change, and I can see how this opens up future possibilities. Plus I’m sure using the API allows Twitch to process things in ways that doing it via IRC does not.
Keep up the good work!

Can someone please help me to understand why improvements to the Helix versions of these commands can only take place once the chat commands have been removed?

 

Personally I had already migrated most of my bot to use the helix equivalents, but I now face multiple changes with no smooth migration path:

• With a channel editor token, I will no longer be able to start/cancel raids

• With a channel editor token, I will no longer be able to run commercials

• Without broadcaster permission, I will no longer be able to read the mods/vips list (yet non-mods can do this via the first-party webchat)

[simon.richter]

I’m a bit skeptical whether this would introduce rate limits for moderation tools simply through endpoint connection limits, both on the TCP/load balancing level, and on the API level.

Some of the moderation tools we use do generate quite a few commands in a short time, e.g. we have a function to quickly ban all people with a first chat message in the last ten minutes, or a function to convert all VIPs into moderators for a few minutes to help with cleanup, then mass-demotes them again.

If we switch this over to use single API calls using a persistent HTTP connection, will there be limits we need to be aware of?

[BarryCarlyon]

@simon.richter

or a function to convert all VIPs into moderators for a few minutes to help with cleanup, then mass-demotes them again.

The /vip (and /mod) chat command has the same limitation has the API (10 users per 10 seconds give or take). So you can’t do bulk VIP/MOD operations regardless of which method you vip/mod via.

[prod]

as barry already covered the documented vip/mod ratelimit (note: these are actually independent buckets), i’ll answer the undocumented part: the rate limit on helix banUser can be found here (but this is unofficial, so could change at any time).