Deprecation of chat commands through IRC

Announcements
61

If the case is that it does consume from two buckets, then it feels like there is a major miss in the design of the moderation API. Especially if the idea is to remove the commands through IRC.

The reasoning behind that statement is purely when you want as I described above, a “bot” user token. That can be utilized to do automated moderation for many channels. But if the max limit of moderation becomes the “global bucket”, then we are limited to 600 moderations per 60s as you wrote above. Instead of the previous 100/30s through the IRC.

So back to my previous question, what is the idea, what are the plans, and could we get some clarifications regarding these concerns/questions.

1 Like
62

huge agree here. the fact that there’s (seemingly) an undocumented rate limit is scary.

2 Likes
64

What about the new /shoutout command? Will there be API or IRC access for that to allow for simultaneous triggering with existing bot !so commands?

65

UserVoices for Shoutout command API requests

And heres pinned messages

Currently /shoutout is in the same state as /announcement no third party support after launch to the world (then we sorta got partial bot support before they gave us a proper API, but I doubt they will give us initial bot support and wait until they build the API instead)

we really need more day 1 APIs for new features

66

Im not sure why you have to move away from irc without a better solution then the api (which is realy awefull) besides the fact twitch got the worst and most broken api, it might be not that good to move from irc to that api.

Besides its a mess to work with and i can understand why the most dont even dare to work with

67

If it’s so awful, have you written up UserVoices for feature requests to improve it and your use case for those features? Or for all of the issues that you seem to struggle with have you asked for help on any of the developer communities, or posted a bug report on Github so that it can be looked at and resolved?

I’m not sure where you’re getting your data that most don’t dare to work with it, as it has better documentation than most services open to third party developers, and the size of the community allows for lots of tutorials, guides, and support for people getting started over the years.

68

I watched the dev stream today and I appreciate y’all addressing many of the points brought up. For those who did not see the stream today, I’d ask to consider a post update in here addressing the points, even if it’s a “we’re discussing it.”

Specifically about get mods/VIPs, I understand the reasoning behind broadcaster tokens, but I’d ask to consider allowing moderator scopes as a compromise.

The two new follower endpoints mentioned will need a moderator scope as well (mentioned during the stream), which implies moderators will be able to access follower info. I’d say VIPs and mods are similar information and can follow suit.

Just my two cents ¯\_(ツ)_/¯ And yes my two cents are in the uservoice :slight_smile:

1 Like
69

From the dev stream today:

For a long time, there has been this unfortunate segmentation of functionality across the Twitch API and IRC. For example, until we recently launched the new API endpoint to start a raid, the only way to carry out a raid programmatically was through IRC. So, developers had to manage a Helix client, an actual Twitch application, as well as an IRC application to access all the actions that you could take on behalf of a broadcaster. So therefore, we are deprecating these actions through IRC, which will group all actions under the Twitch API with our latest endpoints, and this is really stemming from some improvements we want to make to Twitch chat, and we cannot do that easily or effectively with these things as they are.

(clip, accidentally made with my bot account: Twitch)

I find this justification really strange. Specifically that you’re justifying removing commands from TMI entirely by saying some developers needed to maintain both a Helix client and an IRC client.

My bot (which exists specifically to delete links from chat) worked perfectly fine with just an IRC connection, but thanks to this change… I now need to maintain both a Helix client and an IRC client. For developers like me, this doesn’t simplify things, this makes things more difficult: I now need to maintain two clients within my bot, concern myself with two different rate limits (in addition to the already-discussed confusion around what the Helix rate limits are), and take actions using two different APIs. Previously, everything happened only over the TMI connection.

Given you’re making things more complicated for me, removing the features that let me keep my bot minimally complicated, it’s hard for me to have that trust that Jon mentioned that you’re doing the right thing for 3rd-party developers. You’ve added more surface for bugs and flaws, more things I need to keep track of, more errors I need to handle, and more information I need to provide in my bot’s configuration, and you’ve provided justification that reads, to me, as the opposite of reality. And while I’ve already updated my bot, it’s hard for me to see any benefit to the changes from my perspective.

Really, all I can say is that hearing the discussion today was frustrating, given the disconnect between my experience as a bot developer and the way you’re discussing the changes. And it makes me worried for the future of TMI and my bot—is TMI going to be here at all in two years? Will I have to completely rewrite my bot (again) to use another, completely different API if you decide that it’s too much of a hassle for developers like me to maintain two connections, now that I require two connections?

I’m hoping you can provide more info on what the changes you want to make to chat are soon, because I’d like to trust you, but I can’t with the information you’ve given me.

3 Likes
70

I actually asked this specific question in the Q&A segment as well: Twitch

It seems if I want to which channels a user moderators for, the best shot I have is (using their token):

  • Read the user’s complete follow list (up to 20 api calls)
  • Attempt to execute a mod-restricted helix endpoint like Get AutoMod Settings (up to 2000 api calls)

So, I’ll end up doing up to 2020 api calls per user, which will take up to 3 minutes to execute within the rate limit.
I guess this is what Twitch is forcing upon us by maintaining an artificial restriction (as /mods continues to be public via webchat)

2 Likes
71

1000% with demize.

I’d hate to put all this effort in to migrate to helix, then be told IRC will be going away too. I realllllllllly hope these changes that we need to “trust” y’all about don’t involve yet another rewrite/migration. Please be more transparent about these, very soon™.

1 Like
72

Prepare yourself; it’s chat over eventsub

73

When any of my bots start, the first thing it does is ID to username lookups via helix to check if the user changed their name (or the bot did) or not and ensure I connect to the right channel. Do you not do the same? Or even do a token validate/refresh call? (Sure thats not quite helix but still curl/http)

You don’t need a full “helix client” just a curl client for the calls you need.

A “curl client” that does a token maintaince check? And Hopefully does what I do (id to name checks) to check for the destination/target channel names in cases of renames?

First party also calls an API and doesn’t use the TMI socket. This change will bring the “3rd party experience in line with the 1st party expereience” potentitally reduce such a surface. So the exact opposite in my opinion.

It’s still the bots own token for moderation tasks, so if you are maintaining a token for your bot to login wot chat with., you don’t need any more configuration?! Beyond seeding the token with additional scopes when generating brand new token sets.

That I feel was half in jest and even then, wouldn’t replace whatever is used to deliver chat “normally” in my opinion, so would be an option.

Imagine if it supported filtering and you could ask twitch to only send chat messages you are interested in for example.

74

What my bot did previously:

  1. Connect to TMI using an implicit grant flow token from twitchapps
  2. Join the channels it’s supposed to be in (including its own, based on the username in the config)
  3. When it sees a message that breaks the link rules in any of the channels that have added it, /delete them using the message ID from the TMI message and send a message notifying the user over TMI (both using the channel in the IRC message)

What it does now:

  1. Connect to TMI using an implicit grant flow token for an app I had to register (no change there, other than the token itself)
  2. Use the client ID that’s now in the configuration file (there’s the new config) to reach out to Helix (there’s the new Helix client) to determine its own user ID based on the username provided in the config
  3. Join all the channels it needs to be in
  4. When it sees a message that breaks the link rules in any of the channels that have added it:
    1. Send a request through Helix to delete it (using its own user ID, its own client ID from the config, the broadcaster ID from the TMI message, and the message ID from the TMI message)
    2. Reply to the user notifying them their message was deleted over TMI (using the channel from the IRC message)

Maybe from Twitch’s perspective, but not from mine. I can tell you two regressions in my bot already, from me updating it and failing to consider all the differences between sending commands through Helix and TMI. First, it lost the ability to tell when its commands are being blocked (because someone added it to their channel and didn’t add it as a mod) and put a channel in jail for a bit, because I was relying on NOTICEs from TMI for that (easy fix, but the more obviously scary issue). It also broke my metrics, which is a harder fix, and more annoying to me; since my metrics were provided through the crate that handles my TMI connection, I need to figure out how to piggyback on that and send my own metrics, and redesign my Grafana dashboard to show new metrics.

When you add in additional components I need to use, there’s more ways for me to mess them up. And it’s not like development is my job; this is something I maintain mostly because it solves a problem a friend brought up with other mod bots in a discussion in their mod chat and I figured “hey, I can write a bot that does better” (and I did! it works pretty well, in my channel and the few others that it’s in). I spent the time to get it working, rewrote it entirely to change languages, but I have a full-time job and my bot isn’t it. I imagine most bot and extension devs on Twitch are in similar situations, where they can support their product, but only really in their free time. Adding on a second API that we have to use means we have to write a significant amount of new code, and that code can have issues, and even if we managed to prioritize updating the code to use the new API (to make sure our product doesn’t stop working in the future) those issues can linger.

And hopefully you can tell from my brief descriptions of my bot’s flow before and after that this is some pretty significant new stuff I need to do, in addition to most of the old stuff. That counter to the justification from Jon in yesterday’s stream, this isn’t removing complexity by letting me do everything over Helix, it’s adding complexity by making me use Helix when I had no reason to before.

Thankfully I think the only person running my bot is myself, so it was a transparent switch for any of the people using it, and nobody else has to worry about registering an application and adding a client ID to the config… but I know there are other open-source bots out there people use, and there are probably going to be a lot of people needing to do similar updates pretty soon.

75

USERSTATE on channel join tells you if you are a mod or not. So you can check your permissions on room join, rather than after trying to run a delete command.

And, as you already found, replace TMI notice checks with helix 2xx or 4xx responses (that will also describe the issue in the body).

I would also argue this is better as you get a positive reply to your individual command.
Where as if you were to run two deletes in the same channel at the same time, you won’t know which one failed and which one succeeded, if one of the two attempts failed for whatever reason. (Sure ignoring IRCv3 nonce tag which you might not be using and I don’t remember if it works for this request as not documented)

Arguably the wrong token type since every 60 days you are going to have to manually provide your bot a brand new token. if you remember. (or wait for the first fail from a dead token).

You ought to be using the “regular” code flow that grants a token and refresh token. And then you have no manual steps (except in rare cases where the refresh token is invalid).

Sure you’ll need to renew the token with the refresh token every 4 hours. But you won’t need to manually provide a new token every 60 days when the implicit token dies.

I disagree I fully ported in about 3 hours from TMI commands to Helix on my bot for all features that needed swapping. But as I described I already had some HTTP calls in place for token checks and destination channel checks.

76

Then the documentation should address this–I used the same oauth token for nearly a year with TMI (the one I generated with twitchapps), and the documentation isn’t exactly clear on when implicit grant tokens expire (or whether they expire; the only mention I can see is the “Tokens don’t last forever” heading itself or the examples for the other two flows).

And this isn’t really helping the case that it’s supposed to be simpler for me, either… because now instead of the implicit grant token I used successfully for a year, I need to implement code to refresh the token every 4 hours. It looks like the crate I’ve been using for TMI can do this for me (which is much better than having to do it myself) but it’s still another moving part that I have to worry about.

77

Your token was from TwitchApps as you said. And that is an ancient ClientID which has “forever” tokens. It’s not “normal” for Access Tokens to last forever.

This is NOT NORMAL behaviour. And at some point old ClientID’s will likely lose “forever” tokens. Also another reason to not use someone elses token generator.

And as you noted “Tokens don’t last forever” in the authentication documentation:

The time isn’t documented as it could change, so the following should be used to determine expiration:

The expiration time is returned from two places:

  • from the validate endpoint
  • in the payload when you exchange a code for a token when doing code auth

So for an implicit token, you dont’ get the expiration time back when generated so you’d have to call validate to get time remaining

You’ll also find that Implict (and app access) tokens, are around 60 days and not exactly 60 days (could be 59 or 61)

So durations not covered as Twitch could decide tomorrow that regular tokens are valid for 6 hours and since developers get the time back on token gen, or can validate to get time left, no one would notice if the time was changed.

And if your Helix call 403’s (I forget off hand if it’s a 403) due to a bad token, you can just regenerate the token and try again.

78

That’s not reliable for knowing if you are a moderator at any point after you join. And you’ll have no way to query going forward (since /mods is going away and the API endpoint is arbitrarily restricted). It’s better to be reactive anyway.

Presumably, that’s because you were "/unmod"ed in between. Otherwise (e.g., the message was already deleted), I don’t know why s/he should care.

Well, I was able to do it, so stop complaining about the inconvenience.

Essentially, Twitch claims that removing functionality somehow makes things more convenient. Here, someone has pointed out how it did the opposite. You acknowledge that you had to take an extra 3 hours that wouldn’t have been required, but disagree that it was inconvenient???

No one is arguing demize’s approach or code is perfect, nor is this the right thread to discuss it, but it worked. This change required additional effort.

79

if you .delete and do a .delete immediately after as the describedd case.
You instantly delete two messages.
So a unmod in that window is unlikely.

it takes a finite time to update anything when anything changes. Or new API’s are added.

I did work when the announcements API was added. And I will do more work when shoutouts or pinned message API’s are added.

Doing work/spending time to update code when changes occur regardless of the type of change occuring.

Sure it’s may be an inconvenience as you put it. But work to support streamers to do what they need to do or want to do via the available API’s is just work. And continuing to support streamers to do what they need to do is not an inconvenience to me.

The same thing happens in any market segment as a developer. API’s change or update things are added or removed. Whether thats due to external factors (do not get people started on GDPR) or the services makes changes.

This change Twitch is making is what it is, things get added and removed or changed.

Nothing has been removed it’s just changed how it functions. It’s all moved from the socket to helix which brings third party operations inline with first party operations. Since first party isn’t sending these commands over the socket.

So sure its an inconvenience for third parties but better in the long run if things are “common” again between third party and first party. So we should get new features as quickly as first party does.

So is new features an inconvenience to you? (Like the announcements API thats a new inconvenience feature to you?)

You also get a USERSTATE in reply to regular PRIVMSG’s (as least periodically) iirc so you can track it there.

Or just process the 4xx body response when you do an API call to do a moderation action.

Or to every moderation task are you making a “am I a mod” call each time first?

80

And?

There is a big difference between being resigned to doing more work as necessary and defending the need to do (what should be) unnecessary work.

I feel like you’re trying to make a semantic argument here, but…

remove v.

  1. take (something) away or off from the position occupied.
    They will take away chat commands from chat.
  2. eliminate or get rid of.
    They will eliminate that functionality from chat.

That is irrelevant, has never been the case, and likely never will be. In this case, Twitch will continue to maintain access to the chat commands from the website and won’t be using “common” APIs to do it.

There is a difference between adding features and removing functionality. I can add support for new features when and if I feel like it. In that case, that feature just won’t be available for a while. In this case, basic functionality will be broken.

I said it’s better to be reactive. If you have no reason to believe you are not a moderator, then you might as well proceed as though you are one, and adapt as warranted. I didn’t write demize’s code, and I don’t dictate the right way to do things.

That doesn’t mean I can’t complain when breaking changes are made, and moreso when the justification is illogical. It’ll somehow enable new chat features, make things more consistent, and more convenient. There’s some serious doublespeak going on here.

81

As mentioned to you earlier in this thread, Twitch hasn’t sent the commands entered on the website over irc for ages but instead sent them to an API, so you’d be incorrect in saying they wouldn’t be using APIs to do it but its rather the opposite, we as 3rd party devs weren’t using an API to do it while they where using an API for months

Basic functionality won’t be broken its just requiring an update.

Like mentioned before in this thread and this post it does make things more consistent, 1st party and 3rd parties all using an API rather than 1st party using an API and 3rd party sending commands over IRC. There’s no double speaking going on as both using an API would be consistent while 1st party using an API and 3rd parties using IRC as is the current case would not be consistent.

1 Like