This week, we introduced a new chat badge to help viewers identify chatbots that are present or participating in the chat conversation. The images below demonstrate how the badge can be displayed with a chat message and how the chatbot can be shown in the viewership list. These features are automatically applied when specific criteria is met and will override any existing global badge.
The viewership list displaying a bot in the new “Chat Bots” section.
As a developer, how can my bot use the Chat Bot badge?
The Chat Bot badge will automatically display next to a message when your bot uses the Send Chat Message API endpoint with an app access token, and has the channel:bot scope or moderator status for the channel.
As a developer, how can my bot appear as a Chat Bot in the viewership list?
Your bot will automatically be displayed in the “Chat Bots” section of the viewership list when listening to chat via the Channel Chat Message EventSub event with an app access token and has the channel:bot scope for the channel.
Will the badge appear in my bot’s profile card?
Yes, when the Send Chat Message API endpoint is used and meets the requirements above, the Chat Bot Badge will be display in the profile card. The badge will remain in the profile card for 48 hours unless a message is sent manually from the account as a typical, logged in viewer.
Can the badge be displayed if I use a user access token?
No, an app access token is required.
For more information on these features, refer to the Chatbot Badge and Chat Identity section in our developer documentation. And if you have any questions, please feel free to comment below or join the TwitchDev Discord sever for assistance.
Am i correct in saying that this is an attempt to move developers more towards eventsub + helix api over irc? Since it doesn’t appear that there is a way to utilize this with the (guessing) far more heavily utilized way that bots interact with chat, it’s a little confusing why that choice would be made.
It’s a little concerning to me as it seems like the rift between bot and user apis grows ever bigger, and I could see this as an early warning sign that irc for bots is on its way out.
When announcing Chat via EventSub Twitch has made it clear that, while there are currently no plans to sunset IRC (at least there apparently weren’t any back then), new features would be prioritized to work via EventSub + Helix. We haven’t seen pretty much any changes to IRC since then and I would not expect that to change for anything other than security issues.
I still don’t really think we’re on the verge of seeing IRC being shut down (although I would 100% expect that to happen at some point in the future), but migrating to EventSub, if somehow feasible, is probably the right move to make. They have been very clear about that being the future and IRC being more of a legacy option kept around for compatibility.
And at least for this feature I can for once fully understand why Twitch is doing it this way, there simply isn’t any way to differentiate between a normal user or a bot on IRC, since the only option for connecting that way is via a User Access Token, while on EventSub you have the option of checking for an App Access Token and specifically the channel:botscope.
I just wish timeouts weren’t handled so bad via EventSub (no way for the timed out user/bot to see for how long they are actually still timed out for, all we can do is try to send messages periodically until it works lol), but other than that I have not found any limiting factors for migrating so far, at least when it comes to my usecases. EDIT: https://twitch.uservoice.com/forums/310213-developers/suggestions/48972260-improve-error-messages-for-send-chat-message Here’s the relevant UserVoice for the issue if anyone wants to upvote , not that I really have high hopes for it actually being addressed)
Would be nice if this also applied to chat announcements as they currently do not work the same as sending regular chat messages with an App Access Token.
As of right now those chat announcements are appearing without the Chat Bot badge.
My bot application allows channel owners to log in a bot account of their own to have a personalized bot on their channel. This requires a user access token because the application runs locally. The bot badge, however, does require an app access token. Is there anything planned to allow bot badges for bots utilizing user access tokens? I feel like it would be desirable to mark as many bots as possible for the sake of transparency. It’s kind of weird that some bots are excluded and don’t even get any kind of opt-in.
I second the user access token badge idea. If the idea is to make it transparent that a user is a bot to begin with, I feel it does not make sense for user access tokens to be excluded, especially since arguably they require less permissions than an app access token to send a message.
The complexity of a user access token for assinging this badge, is that anyone using a third party chat app (such as chatty) would then be flagged as a bot. (sure the badge service could do additional checks such as checking for does the clientID have channel:bot (a unneeded scope when using user access tokens) but thats extra work for the service beyond “basic” auth/scope checks)
Since those chat apps can’t use app access tokens, the logic is clear(er) on determening said badge.
Perhaps what could also be helpful is knowing the various situations where apps currently using User Tokens can’t migrate to using App tokens, so that where possible support can be offered by Twitch and 3rd parties who help with guides and knowledge. And if there are situations where there’s no choice but to use User Tokens, it will at least raise awareness of those specific use cases and why that’s the only possible option for them.
Most bots run on IRC for a reason; it’s significantly less complicated.
What in particular with EventSub are you finding complicated? It boils down to make a websocket connection, get sent a session id, use that session id to subscribe to chat topics.
There are also benefits of using EventSub instead of IRC, particularly for multi-channel bots, so many bots have already migrated to utilizing it.
Honestly in my opinion the only reason IRC could be less complicated is because there are so many libraries that exist for it by now, the overall flow for EventSub is much less weird.
Open WebSocket → get socket ID → send subscription request → get standardized JSON responses
Sure, if you have a library where you make a bot.connect(username, auth, channel) call that will seem easier than EventSub, but that’s only because the library did all the annoying stuff for you. Rolling your own EventSub subscription is <10 lines of code + whatever structs you might need for storing data if using a typed language and the more popular EventSub gets, the more libraries will offer a wrapper for basic chat functionality as well (even though that full implementation is honestly at max a few hundred lines of code, including data structs and error handling, if you need only chat related functionality)
TMI has so many weird undocumented behaviors and doesn’t even use standard IRC (quoting @BarryCarlyon: “Twitch doesn’t follow the RFC. TMI is a bunch of go scripts wearing a trench coat pretending to be IRC and speaking French.”), so you’ll more than likely need a custom parser for it, unless you can find a library that does it for you. And those are definitely a lot less common than having a JSON parser available to you, most of the times that is something built into the language’s standard library by now.
Not that EventSub is perfect by any means and I do have my issues with it, especially regarding chat, but those are not down to how it works fundamentally but more with, I assume in part intentional, decisions/mistakes Twitch has made regarding specific Events and Helix Endpoints. The Foundation is a lot more standardized and straightforward than TMI ever was.
Oh random side thought with user access tokens, they are not “safe” for this determination as anyone can take the clientID and generate a implict token to send to chat with and the “inference” between the pairings (channel/user) could get used to allow invlaid users to be bot tagged…
And conceptionally there are valid reasons for some bots to be running off an implicit token, since subscriptions exist after a token dies and it could be say a log bot that doesn’t ever need to send. Or it’s a reciver bot that forwards messages to another service that does sending/etc.
Hi,
I successfully aquired the ChatBot badge, I am using the .net twitch lib (github) and a self written wrapper so I could achieve that.
My question is now are there any plans for the WebSocket protocol to be usable using the APP AccessToken? I can successfully register the required eventPub via WebSocket and User Oauth.
but the requirement for appearing in the viewership list are that you are NOT using User Oauth. So you are forced to use WebHooks (public domain required and certificate etc.), because that’s the only protocol where you can use APP AccessTokens.
Thank you! Just wanted to report back to say that this worked for me. It was still a learning process, so I ended up discovering that the conduits really will be created persistently for each client_id and that the maxium is 5. it is fine, because I can delete them (if needed). But with conduits I can indeed use app based access tokens via websocket protocol.
Great update it’s fantastic to see Twitch clearly distinguishing chatbots with a dedicated badge and chat identity.
A couple thoughts and questions:
This will really help users recognise when messages come from bots vs humans clearer transparency is always a win.
Will this badge also help in moderation workflows (e.g., filtering or logging bot-messages separately)?
I noticed the question about WebSocket protocol + APP Access Token. It would be awesome if that was supported too gives more flexibility for bot architecture.
Thanks for the improvement and looking forward to seeing how it rolls out!
, not that I really have high hopes for it actually being addressed)
I think mostely it just exceeds the size of things in comparison to the spec.