TLDR for busy people: My bot system consists of a desktop client app and a web server. Users create accounts on my service, and those accounts have variable permissions that determine what features they can and cannot use. Users connect to the web server from the desktop client, and the web server handles all IO with Twitch and relays messages to the desktop client. The bot service will only join the channel that the user specified when creating an account, where the user was asked to authenticate with Twitch’s API to prove it’s them.
-
The current design has users also creating a secondary Twitch account to act as their bot in chat. The bot server logs into these secondary accounts on the behalf of users. Under this design, there is no “global” bot account like Nightbot for example. Is it always bad and against the rules for a server to log into chat with tons of different Twitch accounts simultaneously from the same IP? Spammers and viewbotters are bad, but are there any exceptions?
-
Users would be sending OAuth tokens to the server, generated for their secondary Twitch accounts, which the bot server would be using to log in to these accounts with. Even though the tokens would be encrypted on the way to the server and then discarded (never stored for any reason), is this always a no-no too?
The purpose of this design is 100% customizability for the users of the bot, from the name of the account to the profile page to the actions the bot performs - while also making the web server the gatekeeper, disallowing access to the bot’s features to those who have been banned or suspended. Keeping the desktop client unable to talk to Twitch directly is done to prevent hackers from altering the executable and bypassing security and account permission measures, running code in chat through the software in an unauthorized fashion.
I can change my design pretty quickly if this is not allowed or heavily discouraged, I just need some info to be safe. Thank you!
The long story:
Hi there! Wall of text inc, I hope someone out there can help me!
I’ve been developing a chat bot for quite awhile (years), and in the past year or so I’ve decided to go large-scale with it and develop a whole service around it. Users will create an account on my service by authenticating their Twitch login, thus making the actual bot always connect to their channel and no one else’s.
By having an account, they will also have access to their own cloud saves and bot profile data, and other goodies tied directly to them. There may also be premium services tied to the bot (cloud saves might even part of that), and access to the bot itself may also be tied to a subscription service on some level. The paid service stuff is still up in the air, I know I want to do it (because I’m putting a hell of a lot of work into this and the feature list is quite huge), but I also want to be as lenient as reasonably possible.
Now, going the service based route and especially a permission/gating system like paid access to certain features changes things a bit. Security becomes a big concern early on. The meat of the bot’s logic is in the desktop client app. This client app used to have the code to connect directly to Twitch IRC, but I have since omitted that code and put it all on my web server. This means that the client app is now more like a dummy terminal - it has communication with my server, which is now handling all IRC traffic to and from Twitch.
The client app asks the remote bot server to send messages to Twitch for it, and if the client is logged in with a proper user account that has the correct access, the server will allow it and act as a middle man. This is much like a client/server multiplayer game, the client can only guess and display what it thinks is happening, but the server ultimately tells it exactly what is or is not happening.
Once again, I’ve done this for account security reasons. If I leave the IRC code in the client app itself, someone could eventually hack the executable, bypass all account permission checks, and connect to Twitch + use the bot’s features without permission. Also, I’m very serious about making sure my bot is not used for malicious or TOS violating purposes. By forcing everything to be routed through my own account based service, I can always see activity from users server-side and restrict access to or straight up ban troublemakers.
This becomes even more important when you take into consideration one of the bot’s major features - an SDK will be released that allows savvy users to code their own plugins, and create just about anything using the bot’s interfaces. If somebody manages to make a plugin that does some bad things Twitch doesn’t like, they can be banned for using such a dumb plugin.
With all that being said, here’s what I’m struggling with right now:
The driving design behind the bot from day 1 has been customizability. The logic is all split up into plugins, which can be turned on/off/deleted/downloaded/developed at will. This gives you the power to make the bot act however you want, within a certain set of rules and limits. Want it to talk like a Zelda character all the time? You got it - you want it to be a boring generic robot? You can do that too. Want it to be completely silent, and just record data for you or ban people that type too many Kappas? Yes. How about a plugin that plays a 3D animation inside its mini-game engine that is captured by your OBS/XSplit whenever someone types a certain command in chat? Absolutely, this works.
This design has extended all the way to the account the bot uses to connect to Twitch with. The goal is to have users create a new Twitch account specifically for their customized bot. This way, the bot’s name in chat and even its Twitch profile would be totally customized by the user. Someone could create an account named KratosBot, download or customize a plugin that made every message the bot sent act like it was Kratos, and so on. A personality so to speak, from the name of the account all the way to the spoken messages.
This was going well, until recently I noticed someone mentioning that Twitch is set up to limit or ban a certain number of separate account logins per one IP. The design I’ve had up until now has your bot client sending the server your secondary Twitch account’s OAuth token every time you want it to join your channel. The token would be encrypted on send, and would never be stored on the server for any purpose. The goal here is that your copy of my bot is named whatever you want it to be in chat, but is also driven by a remote web service.
So, with a lot of people using the bot, a single machine on the web (my web server) would be connected to Twitch with tons of different accounts at once, all from the same IP, which I’ve recently heard is bad, because of the potential for spammers and viewbotters. Also, keeping your OAuth tokens private is obviously a big deal. Even though they would be sent to the bot server encrypted and immediately discarded after login, I understand the need to always keep tokens close to your chest.
So, even though I’ve built in a lot of safety measures, such as only allowing a user to have a single instance of their own secondary account connected to only their channel at any one time, not storing OAuth tokens anywhere, and more - I’m wondering if my design is just invalid by default based on Twitch’s rules? Is one IP connecting lots of accounts simultaneously bad, and always bad with no exceptions?
If I can’t let my web server use people’s own secondary accounts to connect, I’ve already got an account flagged as a known bot that I will use as a global bot account similar to Nightbot and whatever else out there. It kills the name and profile customization that I dreamed of, but I can live with that if I have to. My plugin system is still there 