Special: Discord's Permission Playbook

Jordan: So I was making coffee this morning, and I had no idea what to even call today's episode in my head. Thomas Doan: What do you mean? Jordan: Because there's no server, no owner we lurked in for two weeks. Normally, that's the whole spine of the show. Thomas Doan: Right, no case study this time. Jordan: None. 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 Doan: And I'm Thomas, and instead of a community, we've got documents. Jordan: Policy pages, developer docs, a permission system that's honestly more complicated than most of the servers we've covered. Thomas Doan: It's basically the plumbing behind every server we've ever talked about. Jordan: Which, 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 Doan: And it usually is. But this once, the interesting part is the pipes those people are standing on. Jordan: Exactly. Who gets to control what? Who Discord lets developers touch, and where the company draws the line. Thomas Doan: There's a gatekeeping policy in here, too, around what bots are even allowed to ask for. Jordan: We'll get to that. Thomas Doan: And 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. Jordan: Wait, they reversed it? Thomas Doan: Publicly, in writing. That doesn't happen often with a platform this size. Jordan: Okay, that alone is worth the hour. Thomas Doan: It is. Jordan: So no interview clip this week, no mod chat, just us reading the fine print out loud. Thomas Doan: Which honestly might be more revealing than a server tour. Jordan: We'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 Doan: Go on. Jordan: How big is Discord actually right now today? Two hundred million. Say that number a few times, and it still doesn't feel real. Thomas Doan: It 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. Jordan: Right, and monthly is the bigger, more honest picture of the whole user base. Thomas Doan: A 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. Jordan: So 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 Doan: That's the gap. Ninety million logging in on any given day, more than double that logging in across a month. Jordan: Which 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 Doan: Exactly. 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. Jordan: Okay, so if there are two hundred million people showing up across a month, where's the biggest concentration of them? Thomas Doan: One server. The same roundup names Midjourney's server as the largest known Discord server anywhere, sitting at roughly twenty to twenty-one million members. Jordan: Twenty million people in one server. Thomas Doan: One server. Picture a city bigger than New York, all inside a single set of channels. Jordan: That's an absurd amount of people to moderate with the same tools a thirty-person friends server uses. Thomas Doan: Which 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. Jordan: Lets 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 Doan: We 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. Jordan: So 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 Doan: Exactly 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. Jordan: Which is a good argument for why the boring plumbing question ends up mattering more than it sounds like it should on paper. Thomas Doan: That's basically the thesis of the whole hour, if I'm honest. Jordan: Let'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 Doan: The roundup also notes Discord filed a confidential S-1 on January 6th, 2026. Jordan: A confidential filing, so we don't get the internals, just the fact that the filing happened. Thomas Doan: Right. It's a paperwork step toward a possible public listing. Nothing more we can read into it from what's public. Jordan: Which 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 Doan: No interview clip lined up either, no mod walking us through their setup. Jordan: It 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 Doan: Today, 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? Jordan: So instead, we're working from documentation, filings, changelogs. Different kind of episode, but the questions underneath are the same ones we always ask. Thomas Doan: Which is, who actually holds power inside a system this size? Jordan: And two hundred million users, twenty million in a single server, that's the scale question answered. Now I want the mechanism. Thomas Doan: Meaning what actually holds twenty million people in one server together without it collapsing into chaos. Jordan: Meaning that, yeah. What's actually running underneath all of it? Thomas Doan: Permissions. 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 Jordan: So 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 Doan: That'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 Jordan: All right, walk me through it. Bypass slow mode, so that's for getting around the cooldown between messages Thomas Doan: Exactly 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 Jordan: Which is a much bigger permission than just skipping a timer Thomas Doan: Way 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 Jordan: So a mod can hand that out on its own now Thomas Doan: Right, without also handing over delete powers they didn't wanna give Jordan: Okay, give me another one, though, because you said there were a few of these splits Thomas Doan: The bigger one is events. As of a February 2026 change, Discord's developer changelog says bots now need a distinct permission called CREATE_EVENTS Jordan: Instead of what before? Thomas Doan: Before, a bot just needed MANAGE_EVENTS, and that one permission covered everything, creating an event, editing it, canceling it, moving the time around Jordan: So 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 Doan: Every single one, even events it didn't create Jordan: That seems like a lot of trust for a bot that just wants to say, "Game night, Friday, 8 PM." Thomas Doan: That's the whole point of the split. Now, creating an event is its own line item, separate from managing ones that already exist Jordan: Walk me through why that actually matters day-to-day, not in theory, for someone actually running a role list Thomas Doan: Okay, 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 Jordan: Sure, there's always a tier system Thomas Doan: Right. 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 Jordan: And before this split, giving them event access meant giving them more than that Thomas Doan: It 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 Jordan: Sure. Give me one more example, though, because tier systems like that always have an edge case that breaks the clean story Thomas Doan: Sure. 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 Jordan: Which meant the giveaway coordinator could also edit or cancel the tournament bracket announcement without meaning to Thomas Doan: Right, 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 Jordan: So two totally different roles on the same server stop stepping on each other by accident Thomas Doan: That'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 Jordan: So the granularity is really about not over trusting people by accident Thomas Doan: That'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 Jordan: Does that scale, though? Because more permission types also means more checkboxes for whoever's setting up roles Thomas Doan: It'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 Jordan: Right, because ticking forty boxes correctly is its own kind of work Thomas Doan: Which 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 Jordan: And presumably, the servers that don't care about it just keep using Administrator for everyone, same as before Thomas Doan: Pretty much. This doesn't force better behavior. It just removes an excuse for the people already trying to do it properly Jordan: Okay, so slash commands, events, slow mode, these all feel like fairly ordinary bot behavior, reading channels, posting messages, scheduling things Thomas Doan: Right, nothing there touches anything a user hasn't already agreed to see Jordan: So 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 Doan: Now 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 Jordan: That sounds like a much bigger conversation than a changelog entry Thomas Doan: It is. That's the privileged intent system, and it's a whole separate approval process from anything we've just talked about Jordan: So 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 Doan: Right, and that's a different tier entirely. Discord calls those privileged intents, guild members, presence, message content, three specific ones Jordan: Privileged meaning what exactly? Thomas Doan: Meaning Discord treats them as sensitive enough that a developer can't just flip them on. There's a review process attached Jordan: What kind of review? Thomas Doan: Discord'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 Jordan: So it's not a one-time approval. It's something you have to keep earning Thomas Doan: Every year, yeah. If your bot wants message content at any real scale, Discord wants to look at it again on a schedule Jordan: That's a heavier lift than I expected. Most developer platforms I've seen just gate the initial launch Thomas Doan: This 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 Jordan: Right. That's not can this bot post an event, that's can this bot see your conversation Thomas Doan: Exactly 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 Jordan: So a small moderation bot somebody's running for their 40-person server Thomas Doan: Never even hits the process. It just runs Jordan: Okay, so who's it actually for then? A bot with 10,000 users isn't exactly Midjourney server Thomas Doan: No, 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 Jordan: I 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 Doan: What do you mean? Jordan: Well, 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 Doan: And now you're suddenly in the review lane you spent a year not thinking about Jordan: Right, and you didn't design for that. You built assuming nobody was checking Thomas Doan: I'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 Jordan: Sure, but from the developer's chair it feels the same. You get comfortable, then the rules show up right as you are succeeding Thomas Doan: That'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 Jordan: There'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 Doan: Right. You've crossed into this is actually a project I maintain territory, whether or not you wanted that responsibility Jordan: Which maybe makes the review less of an ambush and more of a formalization of something that's already true about your bot Thomas Doan: That's a more generous read than I had, but I think it holds up Jordan: So it's a trade-off between protecting new developers from paperwork and protecting everyone else from bots that scaled past what anyone vetted Thomas Doan: Which 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 Jordan: And we don't actually know why Discord picked 10,000 specifically, do we? The page doesn't say Thomas Doan: No, 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 Jordan: Fair 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 Doan: As 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 Jordan: Which is kind of the pattern with all of this. The rule reads clean on the page, and the actual mechanics underneath are messier Thomas Doan: And 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 Jordan: Wait, they pushed back on Discord itself? Thomas Doan: Loudly on GitHub, where you can actually watch it happen Jordan: So walk me through this fight. Where does it actually happen? Thomas Doan: On GitHub. Not a blog post, not a press release. A discussion thread attached to Discord's own API docs repo, discussion 5134 Jordan: Developers just show up and argue in the documentation? Thomas Doan: That'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 Jordan: Mm. What were they upset about specifically? Thomas Doan: Part 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 Jordan: Which breaks things that were already working Thomas Doan: Right, 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 Jordan: Okay, so they complain. Companies complain about API changes constantly. What makes this one worth an episode segment? Shortly pause Thomas Doan: Because 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 Jordan: Wait, so the breaking change didn't ship as originally written? Thomas Doan: Not that part of it Jordan: No Thomas Doan: Discord kept the rest of the plan, but cut the piece people objected to loudest Jordan: Incredibly so. That's genuinely rare, isn't it? A platform this size backing off something after a GitHub argument Thomas Doan: It is rare enough that I wanna be careful about what we claim it proves Jordan: Go on Thomas Doan: One 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 Jordan: I'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 Doan: Sure, the transparency's real. I'm just not going to tell you it means Discord always caves when a large enough group complains Jordan: Fair, 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 Doan: Which 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 Jordan: So it's less Discord listens to feedback, and more Discord listens to feedback it can verify Thomas Doan: That'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 Jordan: It 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 Doan: Right, 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 Jordan: Whereas 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 Doan: Which is maybe the real lesson buried in here, more than anything about Discord specifically. Specific falsifiable objections get responses. Broad objections get silence Jordan: Does 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 Doan: No, 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 Jordan: One's a rule, the other's a negotiation Thomas Doan: Right, 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 Jordan: Which is a pretty different picture from a company that just dictates and ships Thomas Doan: It 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 Jordan: You're thinking about something specific Thomas Doan: Voice. 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 Jordan: Meaning what? That it's not something developers get a say in? Thomas Doan: Meaning 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 Jordan: So 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 Doan: That'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 Jordan: So 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 Doan: Wait, none of it? I always figured two people in a call would just talk straight to each other Jordan: That's the assumption most apps built around Skype trained us on. Discord's post says the opposite. Everything routes through their own servers Thomas Doan: Even a call with just two friends in a DM? Jordan: Even that, client to server, server to client every single time Thomas Doan: Okay, so why give up this speed? Peer-to-peer usually means lower latency, right? Fewer hops Jordan: The blog gives two reasons. First one's about exposure. Routing through Discord's infrastructure keeps your IP off the other person's machine Thomas Doan: Right, because peer-to-peer means your computer is literally handing out its address to strangers in a voice channel Jordan: Exactly. 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 Doan: That's a real risk, not a theoretical one. People get doxxed off exactly that kind of leak Jordan: Second reason is moderation. If voice ran Peer-to-Peer, Discord servers would have no visibility into the call at all Thomas Doan: So no ability to enforce anything, no muting someone who's screaming slurs, no kicking a raid Jordan: Right. The moderation tools we've been talking about this whole episode only work because the audio is actually passing through infrastructure Discord controls Thomas Doan: Huh. So the centralization isn't an accident of how they built it early on, it's load-bearing for the safety features Jordan: That'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 Doan: Two and a half million people talking at once, and every one of those streams touches a Discord server first Jordan: Every 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 Doan: WebRTC being the open standard most browser calling uses, Google Meet, that sort of thing Jordan: Right. 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 Doan: Control, 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 Jordan: Does 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 Doan: The 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 Jordan: But apparently that cost is worth it for the safety and privacy side of the trade Thomas Doan: That's the bet they're making, yeah. A few extra milliseconds against not leaking someone's home IP address into a public voice channel. Jordan: That'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 Doan: Who gets to touch what, and on whose terms? Jordan: Right. 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 Doan: Which 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. Jordan: So, control over infrastructure and control over data access, they read like two separate policies, but they come out of the same design impulse. Thomas Doan: One'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. Jordan: That'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 Doan: A fairly complete tour of how much control one platform can hold onto while still keeping developers happy enough to keep building on it. Jordan: All right. That's the documentation stretch of this one wrapped. Thomas, want to take us out? Thomas Doan: Let's do it. Jordan: So, that's the special. Permissions, Intents, one GitHub fight, and a voice pipeline that never leaves Discord's own service. Thomas Doan: Worth saying again, this wasn't a normal episode. No Server, no lurking, no mod we talked to. Jordan: Right. We were working off changelogs and developer docs the whole way through. Thomas Doan: Which meant no Server tour either. We just didn't have anything to send you. Jordan: And that felt wrong to skip over. Thomas Doan: So here's the ask. If you run a Server or you're in one that's doing something worth a look, tell us. Jordan: Could be big, could be 40 people in a voice channel at midnight. Doesn't matter. Thomas Doan: Doesn'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. Jordan: Yeah. 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 Doan: Email us at serverrooms@show.com or drop it in our own Discord. Jordan: We read those, genuinely. That's how half our episodes start. Thomas Doan: The other half start with Jordan reading changelogs at 1:00 AM, apparently. Jordan: Guilty. Regular episodes are back Wednesday. Full community profile, an actual person to interview. Thomas Doan: With a server tour at the end, like normal. Jordan: What stuck with you from this one? Thomas Doan: Honestly, that maintainer response in the GitHub thread. A company this size and someone still typed out why they backed off a decision. Jordan: That's the part I keep coming back to as well. Not the size of the thing, just somebody answered. Thomas Doan: It'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. Jordan: A good note to end the odd episode on. Thomas Doan: Send us your server. We'll go lurk in it properly next time. Jordan: Thanks for sticking with the odd episode. See you Wednesday.