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!