Hey Everyone, I'm excited to announce that the chatbot has been successfully reworked and is now live!

This update introduces a more robust system for sending messages, listening to chat commands, and rewards. However, to make these improvements work for you, a small action is required on your part.

What I need from you:

Please re-login to the website. This step is crucial as it allows the bot to rejoin your channel by authenticating your account. Once re-logged in, the bot will subscribe to the necessary topics, and will start receiving your messages again.

Who should care:

Anyone using chatbot-dependent features like the Fortune Cookie, chat responses, etc., or chat commands (e.g., !!skip/!skiptts, !!count)

Why it took so long

We need to travel back a couple of years to understand the context. A good friend, Chefgucciness, requested a "Show Emote" feature. I enthusiastically added it, making it the second feature on the website, right after Text-to-Speech. This decision was both a blessing and a curse. Initially, my system leveraged a chatbot to read channel point redemptions and utilize a "binding" system, well before Twitch introduced APIs for such functionalities. Since the chatbot was already parsing chat messages, integrating "Show Emote" was straightforward. The process was as follows:

1. Wait for a channel point redemption.
2. Parse the reward's input text for emotes, mostly using IRC.
3. Send the information to the streamer's alerts page.
4. Display the emote on screen.

This method was simple and effective initially. However, as more features were added and user numbers grew, the system began to struggle with performance.

Maybe I'm just stupid, or maybe I didn't give enough thought to the chatbot's architecture, but I don't quite understand how anyone manages chatbots with more than 100 users. I smashed my head about a billion times trying to figure out solutions. I faced performance limitations, Twitch's restrictions, and token management. Every significant change meant enduring hours of delay due to IP-based join limits. It was a nightmare.

Large streams posed another significant pickle. Connecting to numerous small streamers' chats was manageable, but large streams overwhelmed the system with a flood of messages, drastically affecting performance. Unlike smaller streams, where chat activity dwindles when offline, larger streams continuously generate significant chat traffic, even when the streamer is not live.

I thought of solutions like:

• Dynamically allocating streamers to new chat instances upon going live to improve performance.
• Exploring containerized and scalable solutions like Kubernetes and Docker Swarm, though they were beyond my expertise.
• Investigating in-memory data sharing options like Redis for inter-chatbot communication.

However, each solution had its own set of drawbacks and required research, which often led back to square one without tangible progress. I like challenges, but these hurdles seemed only to address a fraction of the issues, affecting features used by a minority of users.

So, I waited

I waited for Twitch. I would pester BlueLava in the TwitchDev livestreams about adding endpoints for sending messages over an API. Twitch had endpoint for sending Extension messages over HTTP, so why couldn't we also do the same for a chatbot/user?

Finally after a year or two, we have a complete solution for scaling a chatbot and being stateless. Eventsub (via Webhooks), and sending chat messages over HTTP.

I spent some time trying to figure out the best way to implement it, and I decided to make a express microservice to ingest chat messages, forwarding those requiring further processing to my alerts microservice, which manages channel point redemptions and chat messages.

Right now, the microservice is hosted with Vercel, and unless Vercel goes down we should be fine.

Additionally, I integrated a CI/CD pipeline to facilitate updates to the Alerts microservice. A few components still require decoupling for complete CI/CD integration, but we're getting closer.

Upcoming things

Beyond internal changes, exciting features are near, including Minecraft integrations. Although still in development, both the mod and frontend are complete. My focus now shifts to crafting a server plugin and simplifying content updates.

It's not completely done. The mod is done, and the frontend is also done, but I want to figure out a better way to make a server plugin, and a way to update the plugin easily with more content.

If you have any suggestions for the mod/plugin, please let me know, especially as this project pays homage to my Minecraft streaming days. I aim to accommodate as many use-cases as possible.

Thank you for your continued support of the bot!

Stay tuned for more information about the Minecraft mod.

-- Isaiah