Need some more info on IRC login rules so I can finish my bot's design

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.

  1. 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?

  2. 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 :slight_smile:

While I’m not sure if Twitch limits the number of IRC accounts that can connect from a single IP I do not see any policy reasons why you couldn’t use different accounts.

My concern would be scalability since you would need to maintain an active connection for each user account that is active regardless of how many message it is actually sending in chat. You would also need to strictly enforce the 20 in 30 rate limit for each account to avoid an IP block since you can’t be sure each account is modded in chat or whitelisted as a bot (and you shouldn’t expect Twitch to respond to whitelisting requests for a hosted service like this which also means you can’t use whispers).

I probably would stick to each client maintaining the IRC connection on the remote machine but still route the business logic through the server so messages must originate there before being sent to the client to send to chat. So if the client is reverse engineered it could still connection to chat but wouldn’t be able to reproduce your service.

Hi George, yeah I pretty much have what you described working already. The server creates a new connection for each client that wants to log into their account and connect to Twitch. I’ll be implementing the rate limiting as well. Currently, the really vital stuff is all handled by the server - the clients are unable to perform any business logic as you say. As for scaling, I’ll be doing a limited network test soon, starting small, and increasing the number of allowed connections (and server resources) as needed.

The clients just ask the server to do things for them, including send messages to Twitch - at which point the server will either agree and tell them the result, or tell them they don’t have permission, based on a variety of factors, including account permissions and soon rate limiting. The clients update accordingly to the server’s response.

I’m just concerned about the “one IP = lots of connected accounts” question the most.

Well, I’ve decided to keep both implementations working and supported in my code so I can move forward. I’ll do the hard science and see if my bot gets bopped for using lots of accounts at once. If so, I can flip a switch and everything will turn into singular global account mode :slight_smile:

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