Special: Discord's Permission Playbook

JordanSo I was making coffee this morning, and I had no idea what to even call today's episode in my head.

Thomas DoanWhat do you mean?

JordanBecause there's no server, no owner we lurked in for two weeks. Normally, that's the whole spine of the show.

Thomas DoanRight, no case study this time.

JordanNone. So we're doing something different. This is Server Rooms, the show where we usually pick one Discord community apart, and I'm Jordan.

Thomas DoanAnd I'm Thomas, and instead of a community, we've got documents.

JordanPolicy pages, developer docs, a permission system that's honestly more complicated than most of the servers we've covered.

Thomas DoanIt's basically the plumbing behind every server we've ever talked about.

JordanWhich, when you think about it, is kind of appropriate. We're always talking about servers as if the interesting part is the people in them.

Thomas DoanAnd it usually is. But this once, the interesting part is the pipes those people are standing on.

JordanExactly. Who gets to control what? Who Discord lets developers touch, and where the company draws the line.

Thomas DoanThere's a gatekeeping policy in here, too, around what bots are even allowed to ask for.

JordanWe'll get to that.

Thomas DoanAnd here's the teaser. There's a spot where Discord actually shipped a breaking change. Developers went off in a GitHub thread, and Discord walked part of it back.

JordanWait, they reversed it?

Thomas DoanPublicly, in writing. That doesn't happen often with a platform this size.

JordanOkay, that alone is worth the hour.

Thomas DoanIt is.

JordanSo no interview clip this week, no mod chat, just us reading the fine print out loud.

Thomas DoanWhich honestly might be more revealing than a server tour.

JordanWe'll see if you still think that in forty minutes. Thomas, before any of this policy stuff makes sense, I think we need a number.

Thomas DoanGo on.

JordanHow big is Discord actually right now today? Two hundred million. Say that number a few times, and it still doesn't feel real.

Thomas DoanIt shouldn't, because the number everyone quotes is way smaller. Ninety million daily active users gets repeated constantly, but that's a daily figure, not a monthly one.

JordanRight, and monthly is the bigger, more honest picture of the whole user base.

Thomas DoanA top-down roundup of Discord statistics from August 2026 puts monthly active users above two hundred million, citing Discord's own transparency report, along with material from its IPO-related filings.

JordanSo we're talking a gap of over a hundred million people between the number that gets tweeted around and the number that's actually filed.

Thomas DoanThat's the gap. Ninety million logging in on any given day, more than double that logging in across a month.

JordanWhich makes sense if you think about how people actually use this thing. Not everyone opens Discord daily the way they open, say, a messaging app for texting.

Thomas DoanExactly. Some servers only get active on weekends, some only during a game's launch week. The monthly number catches all that traffic the daily count misses.

JordanOkay, so if there are two hundred million people showing up across a month, where's the biggest concentration of them?

Thomas DoanOne server. The same roundup names Midjourney's server as the largest known Discord server anywhere, sitting at roughly twenty to twenty-one million members.

JordanTwenty million people in one server.

Thomas DoanOne server. Picture a city bigger than New York, all inside a single set of channels.

JordanThat's an absurd amount of people to moderate with the same tools a thirty-person friends server uses.

Thomas DoanWhich is actually the whole reason we're doing this episode the way we are. The permission system has to work identically, whether it's your five-person group chat or Midjourneys twenty million.

JordanLets actually sit with that for a second because the same tools undersells what that means in practice. What does moderation even look like once youre talking twenty million in one place?

Thomas DoanWe dont know Midjourneys specific configuration. The roundup doesnt get into the servers internal configuration. But structurally, the tools on offer are identical, no matter the size: roles, permission overwrites, auto mod, or whatever third-party bots the owner chooses to install.

JordanSo the ceiling on whats possible doesnt change with scale. Its the floor of how much you actually need to lean on that ceiling that changes.

Thomas DoanExactly that. A five-person friend server can run with zero configured permissions, and nobody will ever notice. A server the size of a mid-sized countrys population without functioning role structures would be unusable within a day.

JordanWhich is a good argument for why the boring plumbing question ends up mattering more than it sounds like it should on paper.

Thomas DoanThat's basically the thesis of the whole hour, if I'm honest.

JordanLet's hold that thought because it's going to matter a lot in a minute. There was one more thing in that roundup worth flagging.

Thomas DoanThe roundup also notes Discord filed a confidential S-1 on January 6th, 2026.

JordanA confidential filing, so we don't get the internals, just the fact that the filing happened.

Thomas DoanRight. It's a paperwork step toward a possible public listing. Nothing more we can read into it from what's public.

JordanWhich is honestly a decent way to describe this whole episode. We don't have a community to sit inside this week, a server we joined and lurked in like we normally would have.

Thomas DoanNo interview clip lined up either, no mod walking us through their setup.

JordanIt is a different feeling, not going to lie. Usually, by this point in the show, we've got an anecdote about a channel name or an argument over emoji roles.

Thomas DoanToday, it's PDF footnotes in a changelog def. Less color, but the underlying questions are the same shape. Who has access, who decides, and who lives with the decision after it ships?

JordanSo instead, we're working from documentation, filings, changelogs. Different kind of episode, but the questions underneath are the same ones we always ask.

Thomas DoanWhich is, who actually holds power inside a system this size?

JordanAnd two hundred million users, twenty million in a single server, that's the scale question answered. Now I want the mechanism.

Thomas DoanMeaning what actually holds twenty million people in one server together without it collapsing into chaos.

JordanMeaning that, yeah. What's actually running underneath all of it?

Thomas DoanPermissions. Every single one of those two hundred million accounts is governed by a role and permission system that decides what they're allowed to touch

JordanSo the numbers we just went through are the headline, but the permission system is the part that has to be engineered right or none of it works

Thomas DoanThat's the part I actually wanna dig into, because it's not one simple on/off switch. Discord splits permissions in a way that trips people up constantly, and it's worth walking through exactly how

JordanAll right, walk me through it. Bypass slow mode, so that's for getting around the cooldown between messages

Thomas DoanExactly that. Right now, if a server has slow mode on, say, one message every thirty seconds, that used to be tangled up with other permissions, like manage messages

JordanWhich is a much bigger permission than just skipping a timer

Thomas DoanWay bigger. Manage messages lets you delete anyone's posts, pin things, the works. Discord's developer changelog pulled slow mode bypass out into its own standalone permission

JordanSo a mod can hand that out on its own now

Thomas DoanRight, without also handing over delete powers they didn't wanna give

JordanOkay, give me another one, though, because you said there were a few of these splits

Thomas DoanThe bigger one is events. As of a February 2026 change, Discord's developer changelog says bots now need a distinct permission called CREATE_EVENTS

JordanInstead of what before?

Thomas DoanBefore, a bot just needed MANAGE_EVENTS, and that one permission covered everything, creating an event, editing it, canceling it, moving the time around

JordanSo if I built a bot that just posts a weekly game night event, under the old system, it needed the keys to edit or nuke every event on the server

Thomas DoanEvery single one, even events it didn't create

JordanThat seems like a lot of trust for a bot that just wants to say, "Game night, Friday, 8 PM."

Thomas DoanThat's the whole point of the split. Now, creating an event is its own line item, separate from managing ones that already exist

JordanWalk me through why that actually matters day-to-day, not in theory, for someone actually running a role list

Thomas DoanOkay, picture a mod team on a decent sized server. You've got maybe forty moderators, and you don't trust all forty the same amount

JordanSure, there's always a tier system

Thomas DoanRight. So you've got your senior mods who can do anything, and then you've got event coordinators, people who just run the Friday tournament announcements

JordanAnd before this split, giving them event access meant giving them more than that

Thomas DoanIt meant giving them the ability to touch every scheduled event on the server, including ones set up by other teams. With CREATE_EVENTS split out, you give the coordinator exactly one thing, make new events. Nothing else moves

JordanSure. Give me one more example, though, because tier systems like that always have an edge case that breaks the clean story

Thomas DoanSure. Think about a server that runs a weekly tournament and also handles giveaways through the same events calendar. Before the split, whoever ran giveaways needed MANAGE_EVENTS too, since that was the only door in

JordanWhich meant the giveaway coordinator could also edit or cancel the tournament bracket announcement without meaning to

Thomas DoanRight, purely because the permission bundle didn't distinguish between the two jobs. With CREATE_EVENTS separated out, you can hand the giveaway coordinator exactly the CREATE_EVENTS action and nothing that touches the tournament team's existing events

JordanSo two totally different roles on the same server stop stepping on each other by accident

Thomas DoanThat's the actual day-to-day value of the split. It's not glamorous, but it's the difference between a roles list that matches your org chart and one that just approximates it

JordanSo the granularity is really about not over trusting people by accident

Thomas DoanThat's the mechanism. Broad permissions force you to either lock things down too hard or hand out more access than you meant to. Narrow ones let you match the role to the actual job

JordanDoes that scale, though? Because more permission types also means more checkboxes for whoever's setting up roles

Thomas DoanIt's a trade-off for sure. Discord's changelog isn't claiming every server actually uses these splits carefully. Plenty of servers still just hand out Administrator and call it a day

JordanRight, because ticking forty boxes correctly is its own kind of work

Thomas DoanWhich is why I'm not gonna sit here and say this fixes moderation. It just gives the servers that care about it a sharper tool

JordanAnd presumably, the servers that don't care about it just keep using Administrator for everyone, same as before

Thomas DoanPretty much. This doesn't force better behavior. It just removes an excuse for the people already trying to do it properly

JordanOkay, so slash commands, events, slow mode, these all feel like fairly ordinary bot behavior, reading channels, posting messages, scheduling things

Thomas DoanRight, nothing there touches anything a user hasn't already agreed to see

JordanSo what happens when a bot wants something a lot more sensitive than that, like actually reading the contents of every message people send, not just responding to a command?

Thomas DoanNow you're at a completely different gate. That's not a role permission anymore. That's Discord deciding whether your bot trusts it at all

JordanThat sounds like a much bigger conversation than a changelog entry

Thomas DoanIt is. That's the privileged intent system, and it's a whole separate approval process from anything we've just talked about

JordanSo bots get past this slash command stuff, get event permission sorted, but some of them want more. They want to read message content, see who's in the server, see presence status

Thomas DoanRight, and that's a different tier entirely. Discord calls those privileged intents, guild members, presence, message content, three specific ones

JordanPrivileged meaning what exactly?

Thomas DoanMeaning Discord treats them as sensitive enough that a developer can't just flip them on. There's a review process attached

JordanWhat kind of review?

Thomas DoanDiscord's developer support site lays out a new threshold based on how many users your app is actually reaching, plus an annual reapplication if you want to keep using those intents

JordanSo it's not a one-time approval. It's something you have to keep earning

Thomas DoanEvery year, yeah. If your bot wants message content at any real scale, Discord wants to look at it again on a schedule

JordanThat's a heavier lift than I expected. Most developer platforms I've seen just gate the initial launch

Thomas DoanThis one gates you continuously, which tells you something about how Discord thinks about message content specifically. That's the intent that lets a bot read what people are actually typing

JordanRight. That's not can this bot post an event, that's can this bot see your conversation

Thomas DoanExactly the gap, and the same support page draws a line based on size. Apps under 10,000 users aren't touched by this review threshold at all

JordanSo a small moderation bot somebody's running for their 40-person server

Thomas DoanNever even hits the process. It just runs

JordanOkay, so who's it actually for then? A bot with 10,000 users isn't exactly Midjourney server

Thomas DoanNo, but it's big enough that if the intents get misused, a lot of people are exposed at once. Discord's drawing the line where the blast radius starts to matter

JordanI get the logic, but here's what I keep turning over. Does 10,000 actually protect the small developer, or does it just push the problem down the road?

Thomas DoanWhat do you mean?

JordanWell, say you build a bot as a hobby project. It's under the threshold, no review, no friction. Then it works. People like it. You cross 10,000 users

Thomas DoanAnd now you're suddenly in the review lane you spent a year not thinking about

JordanRight, and you didn't design for that. You built assuming nobody was checking

Thomas DoanI'd push back a little there. The threshold isn't saying small bots are safe forever. It's saying small bots aren't worth Discord's reviewer time yet. Those are different claims

JordanSure, but from the developer's chair it feels the same. You get comfortable, then the rules show up right as you are succeeding

Thomas DoanThat's fair, though I'd rather have that problem at 10,000 users than have every single bot creator filling out a review form on day one. That kills a lot of hobby projects before they start

JordanThere's also a practical angle too, though. At 10,000 users, you presumably have some kind of support burden already. People are filing bug reports, asking for features. You're not exactly anonymous anymore

Thomas DoanRight. You've crossed into this is actually a project I maintain territory, whether or not you wanted that responsibility

JordanWhich maybe makes the review less of an ambush and more of a formalization of something that's already true about your bot

Thomas DoanThat's a more generous read than I had, but I think it holds up

JordanSo it's a trade-off between protecting new developers from paperwork and protecting everyone else from bots that scaled past what anyone vetted

Thomas DoanWhich is exactly the tension the whole permission system keeps running into. Narrow the gate too early and nothing gets built. Narrow it too late and something already has access to a lot of private messages before anyone looked at it twice

JordanAnd we don't actually know why Discord picked 10,000 specifically, do we? The page doesn't say

Thomas DoanNo, it doesn't explain the number, just states it, so I won't pretend to know their internal reasoning. We're reading the same page you'd read

JordanFair enough. Does that make sense as a compromise, though? Annual reapplication for anyone big enough to matter, a free pass for anyone too small to move the needle

Thomas DoanAs a policy, sure. As a lived experience for a developer crossing that line, it's a little rougher than the phrase review threshold makes it sound

JordanWhich is kind of the pattern with all of this. The rule reads clean on the page, and the actual mechanics underneath are messier

Thomas DoanAnd review thresholds are really only half of that story anyway. The sharper fight wasn't quiet paperwork behind the scenes. It played out completely in public when Discord tried to change bot permissions outright, and developers didn't just sit with it

JordanWait, they pushed back on Discord itself?

Thomas DoanLoudly on GitHub, where you can actually watch it happen

JordanSo walk me through this fight. Where does it actually happen?

Thomas DoanOn GitHub. Not a blog post, not a press release. A discussion thread attached to Discord's own API docs repo, discussion 5134

JordanDevelopers just show up and argue in the documentation?

Thomas DoanThat's the venue. Discord posts a proposed breaking change to bot permissions, something touching how interactions and webhooks get gated, and the people who actually build bots start replying underneath it

JordanMm. What were they upset about specifically?

Thomas DoanPart of the change bundled ATTACH_FILES and EMBED_LINKS into the update, so a bot that could already post images or rich embeds would suddenly need to be rechecked against the new permission scheme

JordanWhich breaks things that were already working

Thomas DoanRight, and for a bot running in thousands of servers, that's not a small patch. Someone has to audit every deployment against the new rule

JordanOkay, so they complain. Companies complain about API changes constantly. What makes this one worth an episode segment? Shortly pause

Thomas DoanBecause a maintainer actually answered in the thread and confirmed the attach files and embed links portion of the update got pulled, removed based on what developers said in that discussion

JordanWait, so the breaking change didn't ship as originally written?

Thomas DoanNot that part of it

JordanNo

Thomas DoanDiscord kept the rest of the plan, but cut the piece people objected to loudest

JordanIncredibly so. That's genuinely rare, isn't it? A platform this size backing off something after a GitHub argument

Thomas DoanIt is rare enough that I wanna be careful about what we claim it proves

JordanGo on

Thomas DoanOne discussion thread, one reversal on one specific permission bundle, that's the whole data point. It's not a policy of listening to developers. It's one documented case where they did

JordanI'd actually push a little further than that, though. The fact that a maintainer showed up by name and explained the reasoning, that's not nothing. Compare that to a company that just quietly edits a changelog with no explanation

Thomas DoanSure, the transparency's real. I'm just not going to tell you it means Discord always caves when a large enough group complains

JordanFair, but think about who's in that thread. These aren't casual users. These are the people running bots across potentially thousands of servers. If your infrastructure depends on Discord's permission model, you have a reason to show up and argue the technical details, not just complain in general

Thomas DoanWhich is exactly why I'd guess this one won. It wasn't volume, it's that the objection came from people who could point at exactly which line of code would break and why

JordanSo it's less Discord listens to feedback, and more Discord listens to feedback it can verify

Thomas DoanThat's closer to how I'd put it, yeah. A complaint with a reproducible failure case behaves differently than a complaint that's just frustration

JordanIt also probably helped that it was scoped so narrowly. They weren't asking Discord to scrap the whole breaking change, just the one piece that broke existing functionality

Thomas DoanRight, and that's worth noting as a tactic, honestly. A GitHub thread demanding everything gets rolled back tends to just stall out into nobody agreeing on anything

JordanWhereas keep the rest, cut this one piece, here's exactly why, gives a maintainer something they can actually action without re-litigating the entire proposal

Thomas DoanWhich is maybe the real lesson buried in here, more than anything about Discord specifically. Specific falsifiable objections get responses. Broad objections get silence

JordanDoes that generalize to the intents review process we just talked about, though? Because that one has a hard threshold and an annual cycle. Nobody's negotiating that in a comment thread

Thomas DoanNo, and that's the difference. The intents review is a policy Discord built and controls end to end. This GitHub thread is Discord responding to an objection about a specific technical change in public where anyone can read the back and forth

JordanOne's a rule, the other's a negotiation

Thomas DoanRight, and I think that's actually the more useful way to think about Discord's relationship with the people building on top of it. There's a layer where they set policy and you comply, and there's a layer where if you can show your work, they'll actually adjust

JordanWhich is a pretty different picture from a company that just dictates and ships

Thomas DoanIt is, but it also makes me wanna know where that second layer stops existing entirely, where there's no discussion thread, no comment period, just an architecture decision that's already made

JordanYou're thinking about something specific

Thomas DoanVoice. Every permission we've covered so far, rule hierarchies, event permissions, message content access, all of that happens on infrastructure a server owner or a bot developer has some visibility into. Voice channels don't work that way at all

JordanMeaning what? That it's not something developers get a say in?

Thomas DoanMeaning it's not peer-to-peer, it's not something a third party can route around, and there's no GitHub thread where anyone's debating how that gets built. It runs entirely through Discord's own infrastructure, full stop

JordanSo the same question we've been asking about permissions, how much control Discord keeps versus what it hands to developers, that question doesn't even get to the table when it comes to voice

Thomas DoanThat's what I wanna get into next, because the reasoning behind that choice tells you a lot about what Discord considers negotiable and what it doesn't

JordanSo here's the piece that surprised me digging through Discord's engineering blog. Voice on Discord doesn't go peer-to-peer at all

Thomas DoanWait, none of it? I always figured two people in a call would just talk straight to each other

JordanThat's the assumption most apps built around Skype trained us on. Discord's post says the opposite. Everything routes through their own servers

Thomas DoanEven a call with just two friends in a DM?

JordanEven that, client to server, server to client every single time

Thomas DoanOkay, so why give up this speed? Peer-to-peer usually means lower latency, right? Fewer hops

JordanThe blog gives two reasons. First one's about exposure. Routing through Discord's infrastructure keeps your IP off the other person's machine

Thomas DoanRight, because peer-to-peer means your computer is literally handing out its address to strangers in a voice channel

JordanExactly. A public server with five hundred people in a voice channel, you do not want your home IP visible to whoever's in there

Thomas DoanThat's a real risk, not a theoretical one. People get doxxed off exactly that kind of leak

JordanSecond reason is moderation. If voice ran Peer-to-Peer, Discord servers would have no visibility into the call at all

Thomas DoanSo no ability to enforce anything, no muting someone who's screaming slurs, no kicking a raid

JordanRight. The moderation tools we've been talking about this whole episode only work because the audio is actually passing through infrastructure Discord controls

Thomas DoanHuh. So the centralization isn't an accident of how they built it early on, it's load-bearing for the safety features

JordanThat's their framing, yeah, and it's not small scale plumbing either. This same blog post is about how they handle two and a half million concurrent voice users

Thomas DoanTwo and a half million people talking at once, and every one of those streams touches a Discord server first

JordanEvery one, and the way they push that traffic isn't off the shelf. They built their own media engine in C++ sitting on top of WebRTC

Thomas DoanWebRTC being the open standard most browser calling uses, Google Meet, that sort of thing

JordanRight. So they didn't reinvent voice transport from zero. They took the open protocol and wrapped a custom engine around it for their native apps. Why not just ship the stock implementation? What does building your own engine actually buy you at that scale?

Thomas DoanControl, mostly, on how audio gets encoded, how it recovers from a bad connection, how it interacts with everything else Discord's client is doing. Same instinct as the permission splits, just pointed at a codec instead of a role

JordanDoes that trade-off ever show up as a downside for users, though? Like, is there a cost to routing everything through Discord servers instead of letting two people just connect directly?

Thomas DoanThe blog doesn't frame it that way, but sure, there's an inherent one. You're adding a hop. Client to server to client is never going to beat a direct connection on raw latency

JordanBut apparently that cost is worth it for the safety and privacy side of the trade

Thomas DoanThat's the bet they're making, yeah. A few extra milliseconds against not leaking someone's home IP address into a public voice channel.

JordanThat's actually the connection I wanted to make before we close out. Every thread tonight, the permission splits, the intents review, even the GitHub reversal, it's the same question asked in different rooms.

Thomas DoanWho gets to touch what, and on whose terms?

JordanRight. With bot permissions, it's the developer asking Discord for access. With voice, there's no negotiation on the table at all. The infrastructure just runs through Discord, full stop. No bot developer gets a vote on that architecture.

Thomas DoanWhich tells you something about where the actual boundary sits. Developers get granular controls and occasionally a seat at the table. Infrastructure like voice stays entirely Discord's call. No review process, no opt-out.

JordanSo, control over infrastructure and control over data access, they read like two separate policies, but they come out of the same design impulse.

Thomas DoanOne's about who can move data around inside a Server, one's about who can touch the wires underneath the whole platform. Different layers, same instinct to keep the center of gravity in-house.

JordanThat's a good place to leave the technical side of things, honestly. We went from raw scale numbers into permission granularity, into a fight developers actually won on GitHub, and now into infrastructure nobody gets to negotiate over.

Thomas DoanA fairly complete tour of how much control one platform can hold onto while still keeping developers happy enough to keep building on it.

JordanAll right. That's the documentation stretch of this one wrapped. Thomas, want to take us out?

Thomas DoanLet's do it.

JordanSo, that's the special. Permissions, Intents, one GitHub fight, and a voice pipeline that never leaves Discord's own service.

Thomas DoanWorth saying again, this wasn't a normal episode. No Server, no lurking, no mod we talked to.

JordanRight. We were working off changelogs and developer docs the whole way through.

Thomas DoanWhich meant no Server tour either. We just didn't have anything to send you.

JordanAnd that felt wrong to skip over.

Thomas DoanSo here's the ask. If you run a Server or you're in one that's doing something worth a look, tell us.

JordanCould be big, could be 40 people in a voice channel at midnight. Doesn't matter.

Thomas DoanDoesn't need to be polished either. Some of the best episodes we've done started from a Server that was kind of a mess, honestly, and that was the interesting part.

JordanYeah. We're not looking for a highlight reel. We want the actual texture of how people run these things, the weird bot configs, the channel nobody remembers why exists.

Thomas DoanEmail us at serverrooms@show.com or drop it in our own Discord.

JordanWe read those, genuinely. That's how half our episodes start.

Thomas DoanThe other half start with Jordan reading changelogs at 1:00 AM, apparently.

JordanGuilty. Regular episodes are back Wednesday. Full community profile, an actual person to interview.

Thomas DoanWith a server tour at the end, like normal.

JordanWhat stuck with you from this one?

Thomas DoanHonestly, that maintainer response in the GitHub thread. A company this size and someone still typed out why they backed off a decision.

JordanThat's the part I keep coming back to as well. Not the size of the thing, just somebody answered.

Thomas DoanIt's a small thing, but it's the kind of small thing that tells you whether an organization still has actual people inside it or just a policy team.

JordanA good note to end the odd episode on.

Thomas DoanSend us your server. We'll go lurk in it properly next time.

JordanThanks for sticking with the odd episode. See you Wednesday.