Caching Vs Fetching / The Future of Twitch Bots?

I just wanted to share what i’ve been working on for the past few weeks and the ‘issue’ im seeing with a bunch of current bots.

Here’s a bunch of info that i was testing today/yesterday(i was informed this is INACCUREATE)

Moobot: [1006, 869, 1011, 769, 799, 789, 961] = mean:886ms
Nightbot: [950, 876, 1002, 1008, 788, 766, 789] = mean:882ms
StreamLabsBot: [1131, 1004, 1102, 894, 751, 799, 978] = mean:951ms
Leviathan: [681, 412, 512, 551, 671, 413, 409] = mean:521ms```

Above are the results of each time i called commands that would normally require API calls on the bots cited.
On avarage(inaccurate):

Moobot had an avarage of 886 ms per command
Nightbot had an avarage of 882 ms per command
StreamLabs had an avarage of 951 ms per command
Levitathan(mine) had an avarage of 521 ms per command

As you can see, there’s quite a bit of difference in delay from what i’ve gathered so far.
The highest ping (681ms) barely matches the next lowest ping(Streamlabs 751ms), this is all thanks to Caching.

What im trying to accomplish is to increase the threshold of the Twitch bots with some competition and some results in order to improve the overall quality of bots in the platform.
I’ve personally come from Discord, a platform that encourages and rewards developers to populate their platform with bots to aids the users have an overall better experience, with badges and some other perks.

While those big bots might encounter some big issues with caching, im suggesting the following:
On twitch’s side:
Add Sharing/clustering on your api, that would allow for each node/process to run
individually while taking care of an x amount of streams. This would greatly increase
functionality of bigger bots as their processes can be split and not require a single core to
be running every single channel/stream its working on.

Reward bot devs depending on their accomplishments and what they have to offer to the
overall community of twitch. This would help create competition on twitch bots, which is
case can be used advantageously, without competition, bots are bound to stale, which
decreased the overtime satisfaction. By adding competition, you force devs to push their
content to newer grounds in order to deliver better and more optimized content to the end

Take the previous test that i mentioned as an example, the fact that a nobody dev came and managed to beat some of the most popular bots in terms of response time shows something.
As i mentioned, big bots MIGHT NOT BE ABLE TO ADD CACHING due to the sheer amount of streams they are present in, this would require quite a beefy server with a unglodly amount
of ram(my current host specs: 2x E5-2670 0 @ 2.60Ghz, 128 GiB RAM, 29 IP block(9 Ips, 5 usable) IP4, 2x 960GB Disk, 1 Gbit bandwidth, OCS - Ubuntu 18.04(Bionic)).
While this holds true for professional bot developers, most normal users wont be able to get this much out of their rig. What im recommending is a somewhat good and healthy competition between big bot devs looking to improve the overall quality of bots, be it in dashboards, user functionality, or an overall improvement over its competitors.
Currently, i just wanted to share my thoughts on what Twitch CAN do to increase their bots capabilities to expand its horizon and work alongside with the devs to provide a much better user experience overall.


1) Image CND that renders on the client/ render links from verified bots onto client.

While this may be far fetched, coming from Discord this has been the number 1 feature that i’ve missed.
With image manipulation libraries such as Canvas, this opens up a TON of doors for bot development, specially for custom leveling systems with cards. I’d highly recommend looking into THIS (not sponsored) as a reference for what im talking about.
With this, you’d certainly increase the chat activity to newer grounds, enticing and promoting users to chat as they level up. (this is currently possible and midway implemented in my bot) This encourages users to interact with chat more often than ever as they get rewarded for chatting with some decent visuals(no user likes poorly designed image, thats specially true as to why users request dashboards more often than raw commands, its user friendly)

2)Reward devs with badges/emotes or other way.

This has been one huge good step on Discord’s part, they have been encouraging developers to create bots in exchange of badges for their platform. As a business, this brings a great advantage in terms of functionality as you can use those to advertise and promote your platform. Read this for more info.
In rewarding devs, you also increase the amount of bots in your platform. This is a dual edge sword, in one hand this overpopulates the platform, in a way that ‘basic’ bots are only looking for the rewards. On the other end, this creates competition amongst bot devs to create the ‘better bot’. Nowadays, this is the forumula: Small streamers: Chatbot/moonbot/streamlabs/automod
Bigger streamers: Chat/MoonBot/StreamLabsBot/Automod + 1 or 2 Custom Bots.
From what ive gathered so far, theres only custom bots made PER streamer, theres no competition whatsoever, those are paid bots that work specifically on the streamers end with WHAT THEY WANT.

3) Add a unified/twitch bot list.

A place where devs can advertise their own bots in a way thats fair to everyone. This also opens up market opportunities for investors: lemme develop a bit more on this. Imagine something along the lines of this. This is a website that works by allowing ANY bot developer to add its bots onto its website for it to be added by users that search for something related to what it does. This brings Ads spots, where ADVERTISEMENT spots are MARKED and available for bigger bots to compete with. This brings 2 new things into the platform: A Unified front where the user can search for bots freely and easily and a place for investor to pick in as a business opportunity(with paid features and shares). If done correctly, twitch is granted be able to take advantage of this.

4) More Roles/Permissions

. Roles currently are able to being set per bot, though this brings quite a few problems. 1. Theres no mid way between a USER and a MOD. Thing complicated things with only being able to set VIP as a mid way between the 2. With ROLES you are able to much more freely customize what each user can do and what not. While i do have plenty of example on hand, i’d rather leave this in the hands of twitch to test and check if its a worthy implementation.(In my opinion, having only 4 main roles is quite lacking for such a big platform, those being = USER, VIP, MOD, STREAMER). As a developer perspective, having only 4 mods grants us plenty of doors to access, though it limits quite big the amount of accessibility we can give rto our ‘normal’ users. Patreons, Subs, Normal Users, Common Users, those can barely be distinguished between eachother with only a single role assigned.

Final Thoughts: Most of the experience im bringing in this is due to Discord, and while it may be a big TLDR and being a completely different platform than Discord, in the hopes of a better end user experience i hope for a good change in the community that welcomes the developers bringing in more content for their average users.


  1. Add images to the IRC chat, this opens up plenty of doors for bot developers.
  2. Reward Devs more, devs have no purpose to develop bots, which stales competition.
  3. Unified place for streamers to search for bots.
  4. Increase in Roles. This brings up a lot of doors for bot developers to add ranks/roles to their users.

For reference of those results, this was the method used to calculate each of those results

Command fired by the bot, the counter works the moment the request is sent

chat.send(, !uptime/!other commands);
  collector.on('message recieved' => (filter  = message.username === 'the bot that was 
     being tested'));

After thoughts.

While im creating a library cache, im still working along side with the twich-js development team to bring big bots to the development field. Im currently testing my library cache to make sure it works fine with at LEAST 10,000 streams within a 7 day period with a standardized stable RAM usage without leaks. This should bring a decrease in API calls while also allowing bots to develop their commands much more dynamically as they wont have to rely on the API to provide most of the information needed.

For those who read most/all of it, i bid you a great day that and let us work together to improve the Twitch Developer Community!

You’ve just compared apples to oranges as you have no idea what your delay/relay is between you sending the command and the bot receiving it and no idea what those bots are doing internally before they start to process your comand, the time to takes to get the result of that command the time taken to return the response to chat and you to receive it. Your metrics are flawed due to not being able to time everything correctly at the right timing points.

And you have no idea how long it took for Twitch to relay your message to the receiving socket from your sending your message to the inbound socket of the bot. You don’t have enough information to (basically) state these other bots are doing something wrong. You have too many unaccounted for variables here

So doesn’t surprise me your bot has the quickest response.

Again you have no idea what these other bots are doing before responding to you, or even if any delay is due to “bad coding” on the bots part, since most of the bots you refer to are already doing sharding/clustering.

Oh gawd please no. Most chat users DO NOT WANT THIS

I don’t need rewards, I need more clients whom I obtain from referral from doing good work building customs bots for the people I work with. Custom always wins.

I don’t need recognition in chat/from Twitch, it doesn’t help me or benefit me at all

This becomes a portal of support small streamers and doesn’t really help anyway

I can implement this internally in my bot(s), don’t really need Twitch to add more roles really.

The best bot for a streamer is a custom bot that does exactly what they want/need to.

Custom always wins at the end, the same goes for Discord bots in my opinion


Bots can already split their workloads by channel, if they so choose, and some do run a microservice infrastructure internally on platforms like Kubernetes.

Extensions is the 3rd party solution for displaying rich content.


Addons like FFZ can already render a preview of a link on hover (off by default for obvious reasons). Embedding images in chat would be an AWFUL idea.

If you want a badge, vote for the suggestion that has already been posted Verified Developer Badge – Twitch UserVoice

The most popular bots on Twitch are run by companies who do their own marketing and advertisement, they don’t need a bot list and certainly not pay to be an advertised spot. Outside of the main bots the smaller bots are usually limited in functionality or more niche so a user would have to spend a large amount of time trying to find something that would meet their own specific needs, and wouldn’t help those who want a custom bot built (and Twitch should not be running a job marketplace for devs).

You can do role management on your end, many 3rd party services already do.

I’d also like to echo the words of Barry who made some great points about the data you have collected, that doesn’t really show anything and you have no idea how those other bots are designed or what they’re doing behind the scenes.

1 Like

Correct me if im wrong, but the responsive time from each of the bots listed should be fair in regards to latency, they only receive the events from the IRC chat and not locally. All bots should be receiving the event at the same time and posting it at their respective response times.

You mention this yourself, i do not know nor do i have access to the repo/code that those bots are running in the background. One thing ive gathered so far is the experience i bring from Discord, with most of the libs ive seen not handling sharing.

While i dont particularly disagree with you in this regard of Image rendering, this still holds true for doors opened. A normal user accessing this can lead to some bad results such as NSFW images or the sort. What i propose is a Verified Bot allowed link. Either for quotation, or something along those lines. One big drawback of this IRC is the fact that it relies mainly on Text and not on image*(with exemption of emotes)

This is what precisely stales a bunch of bots, creating an ecosystem of capitalized bots that are always ontop and have no competition whatsoever, thats the core of my 2 cents.

Agree with you, my bot also handles internally roles, though this could be expanded upon Twitch to allow roles to be created giving permissions that can be accessed by the user rather than using the user id and providing them the permissions via the bot. Example, Mute command. Mods have permissions to almost everything in the chat, theres no middle ground between mod and user in my opinion. The ability to timeout users, to use links in chat, and to use plenty of other things are limited per bot, not per permission the user has. Allowing bots to create roles might be far fetched, but allowing users to be assigned special permissions that most bots do nowadays along with AutoChat mod imo increased greatly the possibilities in permission handling per user.

I definitely disagree with this, this only holds true on a top streamer level. Lower end streamers and non affiliate streamers are not able to be granted the same level of care than those who use their means to pay up. It becomes a pay-wall of sorts, where you either pay for a specific feature or end up without any other alternative. While i have my bad points about Discord bots with overpopulation, i also disagree that the user should use their pocket money for specific feature simply due to the fact that there are no other bots that provide similar functionality. While i dont want to take away the money the devs make from providing custom bots, i also dont believe in stalling of bots commands/functions. reinvigorating the space that bots work on without breaking the system allows for more doors to be opened to the end user/streamer to be accessed, I think a middle ground might be achievable where custom bot devs dont lose their income with their custom bots and newer bot devs can introduce new ideas onto the platform

I greatly appreciate the opinion of both you @BarryCarlyon and @Dist , this is me providing my 2 cents of thoughts on how to improve the twitch bot community, not a one sided view. I enjoy reading your opinions on the subject overall and pointing out my own ideals of how to improve at least a bit the ecosystem.

its less about personal gain and more about how to bring more devs onto the ecosystem, though i understand your concern

This is the whole thing i was mentioning before, its less about focus on bigger bots and more about new ideas flourishing onto the platform. Even on Discord, bots like Mee6 and Dank Member have their proper advertise team, its more about focusing on newer devs than on bigger ones

I’ll definetly check this out. I was thinking about Node clustering with IPC for a handler.

Im assuming this is some of the things @Dist has mentioned with 'Addons like FFZ '?

@BarryCarlyon Could you perhaps link a documentation or some guide on how to properly measure this level of latency? my ultimate goal is to improve my skills as a developer, any new information for me is welcome :smiley:

First you’ve have to adjust the bots you wish to test in order to check the time between you/your test code initiating the send and the bot receiving that message. Which means making changes to the bots you are trying to test

Then you have to make changes to Twitch Chats servers to check which servers are involved with the relay between you and the bot you are testing to add timing events, which means making changes to Twitch

Thats just for a start. You cannot test what you want to test as you do not have control over the test environment or able to confirm the test environment behaved as it should.

You might be connected to say, a European chat server, and the bots you are testing as connected to a Canadian chat server, and neither twitch nor you decided to reroute a closest instance of chat to you. For example. Which you don’t know since no control over the test environment.

The other bots you “tested” you don’t know how they connect to/read from/to chat, given their size it’s likely they have alternative agreements with Twitch on how to interact with Twitch, which brings us back to comparing two completely different things

Thats just off the top of my head. What you collected doesn’t take into account a multitude of other variables.

FFZ is a browser extension 3v refers to Twitch Extensions

Also a question, you titled this post as

“Caching vs Fetching”

What do you mean?

Twitch chat is neither cached or fetched.

It’s all “IRC like” over IRC or over WebSockets

ive just changed my main ‘discoveries’ to inaccurate in the post above as a token of good will. My only goal here is to accomplish more as a dev and not to spread misinformation. My apologies for stating false facts. Though now i wish to go to see if i currently can improve the accuracy of my test and perhaps bring a library onto smaller bots to provide caching, which should both benefit the API with less calls and the bots with a lesser response time as they wont be using calls as their main source of information, and instead targeting the cache.

I will take a look at this rn

Any ideas if an IPC cluster would be on par with something like @3ventic stated?

What are you intending to cache?

@BarryCarlyon Here is the Typescript interface that im currently using for my cache

All that is bot developers choice to cache that then and I imagine that all the bots in question do cache data where relevant.

So caching vs fetching is developers choice and the large bots are already caching to save lookups, so not sure what you intend to change?

I know I cache most of the relevant data from a Twitch Channel that my bot(s) need to refer to. Most of the data I need I get from Twitch webhooks.

From what ive gathered at least on JS’s end, there isnt much enabled as far as caching goes when it comes to TMI nor Twitch-js libraries. As you stated, it may very well be that bigger bots just like mine have private repos which handles their caching, though i havent spotted many(if any) library that provides a cache for developers to attach to. This, also, im bringing from a library in discord. Though both are different platforms, both use IRC. More info can be found HERE

Discord forces libraries devs to do caching at the ground level as Discord is fundamentally different in how it functions that the library has to implement caching or the library ceases to function.

Twitch library develops don’t tend to implement this as a lot of Twitch bot libraries don’t even call the TwitchAPI for anything as they connect to chat.

If the bot needs the display name of the user running a command (instead of the username) it’s in the tags of the chat message.
If a bot needs to check if the user is a moderator at the moment they ran a command? It’s in the badges in the tags of the chat message.

Most of the information, pertaining to a user, that a bot would ever need, is sent with every chat message. So a bot doesn’t need to “waste” resources caching it.

If your twitch bot needs to go get the Title of a channel, then you would develop a secondary service that consumes Twitch webhooks. Or the bot itself would go fetch and cache it itself internally, at the choice of the developer, if the bot has a !title command

Discord has a defined set of things that should be cached.
Twitch does not as every bot is different or doesn’t need to

No Discord is not IRC compatible it’s a totally different protocol and communication method.

Running Discord bots myself I’m somewhat familiar with the differences. Even if I don’t run bots that operate in more than one channel/guild generally

I see what you mean, thank you for the feedback <3
My goal is still to create something that handles twitch emotes, chat users cache, user cache, and a bunch of other extra utilities for bots to work with with ease.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.