Available today: Twitch Chat on EventSub, an API for sending chat, and the Conduit transport method for EventSub

Announcements
22

ezgif-2-f7988e09d6

2 Likes
23

great update but:

it doesn’t make sense for chat eventsub subscriptions to be killed on timeout, especially since there is no feedback over eventsub about the timeout length.

even in the first-party interface, timed-out users can continue to see chat.

now, I have to implement repeated attempts to rejoin a channel with exponential backoff that can last up to two weeks since the max timeout length is two weeks. only after repeatedly trying to join over the course of two weeks can I know whether the disconnect was due to a ban or a timeout. this is plainly absurd.

please revert this timeout behavior that is incongruent with raw IRC and even the first-party interface

Screenshot_20240201_133126

3 Likes
24

Is it possible to filter out the chat messages sent from the same client, for example, with the same token that was used to subscribe to EventSub? Consider the following use case: a broadcaster runs a bot app with their user and wants the bot to react to the chat messages they send into Twitch chat from the web UI or OBS or anything else, but don’t want the bot to react to its own messages. With IRC, this was handled automatically. However, with EventSub + HTTP api it goes like this
eventsub_chat
There’s no way for the client to know their own message ID to filter it out. The alternative would be to ignore all the messages from the same user, which is not always desired.

25

if your client is using the Helix Send Chat endpoint you have the messageID of the message sent.

Add those to a “temporary” list (like keep last 10 or something) and ignore them

26

The issue is, I get that HTTP reply after EventSub notification

27

Then if the botID and the userID is the same then you wait before replying/add a delay in and/or you know you are sending a message.

Course if you know you are sending a message and waiting for the response, then you know you have a message to skip and need to wait for the “dirty” send connection to complete before processing any messages from the sending user.

Broadly speaking the issue is running the bot udner the same broadcaster account, which is “IRC bad form” and frowned upon for checks notes the 20 years I’ve been doing anything on IRC.

Essentially this is a “bot has two connections to chat” scenario (one to send and one to recieve so you recieve a full picture), and you either apply the anicent irc rule of “a bot should never listen to itself” or devise a solution.

IRC doesn’t pass the sending message back due to how the RFC states messaging works on IRC. And even then bots would generally ignore their own messages to prevent infinite loops and the like.

So if you want to do what you are proposing you’ll need to devise a solution that fits your requirements.

Failing that you have a feature request and require a uservoice, but due to what I’ve noted above I doubt that would come to fruition. And based on conversations I’ve had around other kinds of filtering I doubt it’ll be any time soon.

Course if you have a bot command reponse that starts with a bot command trigger, then thats on you. And ignoring moderation filtering then this shouldn’t be an issue tbh.