Chat bot with time relevant messages - which approach to not reach rate limit

Hello,

i developed a chat bot using irc (node.js via tmi.js).
it is a “informational chat bot”. it sends informational messages of real-world events, just in the moment they happen. so these messages are time-relevant - i need the messages to be sent as soon as possible.
please help me with technical advice on how you would set this up and avoid rate limiting.

upfront question: is irc the right thing to do at all?
i am not 100% sure i understood eventsub/conduit fully by now and i am not sure if it would be “more” suitable.

the issue:
i ran into rate limiting recently. i know about the 20/30 rule, which applies to my case, since i do not request moderator role (and also don’t want to if not ultimately necessary). furthermore i want to send the messages in the name of the bot twitch account, not in the name of the receiver account/channel.
at the moment I send messages instantly to all connected live channels, but this leads to rate limiting issues.

a simple solution to avoid the rate limit would be to delay each message 1.45 seconds. but this i not suitable for my use case unfortunately.

current situation:
it looks like i can send to 7 channels at the same millisecond.
the 8th message (to 8th channel) gets `NOTICE: #channel_name, msg_ratelimit, Your message was not sent because you are sending messages too quickly.`
Even though this notice was received, the message was delivered to 8th channel anyway - so i wonder if this notice is rather a “you reached the bucket limit” instead of “was (really) not sent”.

The numbers are no exact science, just what i observed.
But still i need to try to avoid the rate limit now. What is the best approach to do so?

idea 1) use multiple connections - one connection for 7 instant messages
i read dozens of other dev forum posts and i came to the conclusion that this a thing, splitting across multiple connections. but will this actually work?
how many connections can i open up simultaneously? is there a limit?

idea 2) spread messages with a sliding window
this does not actually solve my use case, but it may avoid the rate limit - do I have to accept that i need to introduce some delay?
assumption: 7 messages in a burst trigger no msg_ratelimit. so when 8+ messages need to be sent => delay each message
sliding window theory : 8 messages delayed by ~100 milliseconds, 10 messages spaced by ~350ms … 20 messages delayed by 1.45 seconds to stay within 20/30 limit

but this actually makes my 20th user receive the message 30 seconds late
is this a working strategy at all? surely this is better than a 1.45 seconds delay between each message to stay within 20/30. But still not good enough for my use case.
do i just have to accept the fact that i need to space messages?

is there another approach i did not think about yet?

thanks so much for your feedback!

Even with moderator permissions you’ll hit rate limit.

So you’ll have to send till close to the limit and then handle the rate limit and back off.

This won’t work becuase it’s still authing as you to send with.

This is what you would have to do yes

You have to abide by the rate limit and there are not loop holes to get around the rate limit.

Logically you only want to send to channels that are online/streaming so you can/should discount offline channels, that’ll reduce your target/destination count

Thanks for your quick reply, Barry!

I understand there is no way around the rate limit. I want to try to use the maximum message rate available.

Currently I have a dozen users simultaneously live streaming, so I need to introduce a small delay, I get that - that’s not good, but bearable.

What if my user base scales up - let’s say 100+ concurrent active live streaming channels - how would I handle that situation?
I would need to delay the message for the 100th user for 2 min 30 seconds (20 users receive the message in 30 seconds, 5 x 30 seconds)
Is that assumption correct?

For the underlying use case: Is there a better way to deliver time-relevant messages to live
streams?

A temporary solution for growth: Using moderator role in every channel would enable around 100 concurrent users according to the 100/30 rule for mod status.
Includes the problem i need to make 100% sure that every channel has given moderator status to the bot.

Maybe sending in the channels name is the only suitable choice then to avoid the rate limit at last?

By delaying and sending when you have rate limit available?

Depends entirely on the message/reasoning for the message. That may suggest an alternative solution

This has no effect on the global rate limit. Which is the problem you are facing here.

Ja, you’re right. The current solution only works with introducing delay.

So i guess the only real solution is sending in the channels name. This would avoid the rate limit, since it is very few messages per user/channel. Do you agree, Barry?

I don’t agree because I don’t know the use case for sending these messages to these channels.

The use case will help use decide what would work best.

So what is the sort of messaging being sent that needs to be real time across so many channels at once?

it is a real-time sports event notification bot. when something important happens in real world sports, i create a message and send it to the live streamers chat.
so all channels should receive the message as fast as possible

That sound like a better shout as an extension instead and possibly using extension chat. Or as part of a stream overlay if the streamer is covering the event itself. (or what the celebrate the results as they come in)

You’d want to stick to your own bot name as streamers wouldn’t generally want to give out chat send to a “random” developer for security reasons.

So, you’ll either need to ride the rate limits or use an alternative approach such as overlays or extensions.