Thisis Not A Game

Setting Up Thisis Not A Game Without Losing Your Mind

I spent about six hours last month trying to get Thisis Not A Game running properly on a server with roughly 400 members, and honestly it was worse than I expected. The documentation assumes you already know how OAuth2 delegation works, which most people don't. I'll walk through what actually happened and what I learned, because the official guide skips the messy parts entirely. The core idea behind Thisis Not A Game is straightforward enough, but the execution has enough edge cases that I've seen experienced admins mess it up multiple times. It's primarily a verification and anti-alt system for Discord communities, though people use it for various other things depending on how they configure it. The basic flow involves redirecting users through an OAuth verification page, then assigning them roles based on whether they pass certain checks. Simple in theory.

How Thisis Not A Game Actually Works

When a new member joins your server, TINAG intercepts the join event through a webhook or direct API call, depending on your setup. It then creates a temporary page where the user verifies their identity, usually through a second factor or email confirmation. Once verified, it assigns the appropriate role and logs the event. The unverified users get stuck in a limbo state with limited permissions until they complete the flow. Here's what the docs don't mention: the system has a soft rate limit of about 50 verification requests per minute per instance. If your server gets a sudden influx of members, like from a viral invite or a promo, the verification queue backs up and users start complaining. I hit this exact problem when a partner server shared our link during a stream. About 200 people joined in twelve minutes. The queue stalled at around 47 requests, and half the new members never got verified roles. My workaround was switching to batch processing mode, which sacrifices real-time verification for throughput. Instead of handling each join individually, it groups them and processes about twenty at a time. It cut the queue time from twenty minutes down to about three, but there's a lag where new members sit unverified longer than usual.

Installation and Configuration

You need Node.js version 18 or higher. The repository is available on GitHub under the standard open source license, and the install process is pretty standard for a Node project. Clone the repo, run npm install, copy the example environment file, and fill in your Discord bot token along with your client ID and secret from the Discord Developer Portal. The configuration file is where most people go wrong. There are about fourteen settings, and three of them interact in ways that aren't obvious. The key ones are the verification_timeout, role_hierarchy_mode, and alt_detection_threshold. If you set verification_timeout too low, like under thirty seconds, you'll lose about fifteen percent of your verifications because slower connections time out. If you set it too high, above two hundred seconds, you accumulate a backlog of stale verification sessions that clog the database. Eighty seconds is a reasonable middle ground for most servers. The alt_detection_threshold controls how aggressively the system flags alternate accounts. The default of three means it starts flagging after three accounts from the same IP verify within twenty-four hours. This caught a lot of my actual problems, but it also flagged legitimate friends who were all on the same residential IP. I ended up adding an IP whitelist exception for known friends, which took about twenty minutes of manual work but eliminated the false positives.

Common Pitfalls and What I Wish I Knew Earlier

The biggest issue people run into is the database selection. TINAG supports SQLite, PostgreSQL, and MySQL. SQLite works fine for small servers under one hundred members, but once you cross that threshold, query performance degrades noticeably. I migrated to PostgreSQL at around 150 active members and saw verification times drop from about four seconds to under one second. If you're running a larger community, skip SQLite entirely. Another thing the documentation glosses over is the webhook notification system. By default, TINAG sends a message to a configurable channel whenever someone completes verification or gets flagged as suspicious. But if you don't configure the webhook URL in the environment file before starting the service, it silently drops all notifications. I spent about an hour wondering why I wasn't getting any alerts before realizing I'd forgotten that step. Check the .env.example file carefully before deploying. There's also a known issue with the role assignment logic when your server uses server boost levels as role requirements. If a verified user's Discord Nitro boost level doesn't match the role hierarchy in TINAG, it assigns them the wrong role or skips assignment entirely. The fix is to disable the boost level check in settings or manually override the role mapping for boosted members. I just disabled it since most of my members don't nitro boost anyway.

When Thisis Not A Game Falls Apart

I should be upfront about the limitations. The system is not designed for extremely large communities. Once you push past about two thousand concurrent members, the verification bottleneck becomes a serious problem even with batch processing. The alternative in that case is to look at something like YAGPDB or a custom bot built on top of the Discord API with your own verification logic. TINAG simply wasn't built for that scale. It also doesn't handle edge cases involving VPN users or shared network environments very well. The alt detection will flag people using the same internet connection, which means co-op living situations, university dorms, and offices will all trigger false positives. You need to be prepared to manage a support channel where people can appeal their flags. I have a dedicated #appeals channel in my server specifically for this, and I spend maybe an hour a week clearing it out. Security-wise, the system stores verification tokens in the database and session data on disk. It's not encrypted at rest by default, which matters if you're running it on a VPS that gets compromised. I added disk encryption on my server as a basic precaution, but it's not something the project itself enforces. If security is a concern for your community, you need to handle that at the infrastructure level.

The project hasn't had a major release in about a year, and the GitHub issues page shows several unresolved bugs related to the role sync feature and the database migration path from older versions. If you're starting fresh with a clean install, you should be fine. If you're migrating from an older version, expect to spend a couple of hours debugging schema mismatches. I backed up my SQLite database and ran the migration scripts in order, but the v3 to v4 transition broke my existing role mappings. Restoring from a backup and reconfiguring took me about ninety minutes. Overall, for a medium-sized server looking for a straightforward verification and anti-alt solution, Thisis Not A Game does the job reasonably well. It's not elegant, it has quirks, and you'll spend more time tweaking the configuration than you probably want to. But once it's running correctly, it handles the day-to-day verification traffic without requiring constant babysitting. The batch processing mode is the feature that saved me during peak traffic, and the IP whitelist exceptions are essential for keeping false positives down. Just don't expect it to work perfectly out of the box, and read through the entire configuration reference before you start the service. If you decide to try it, the project is hosted at the standard GitHub location and the Discord support server has an active enough community to get answers, though response times vary. I recommend joining that server and searching the pinned messages before posting a question. Most of the common issues have already been documented there.