zorkian
Tl;dr: The vast majority of adults will never have to interact with our age assurance systems and their experience won't change, because we know Discord and how people use it, so we're designing to respect privacy and deliver a safer experience while minimizing friction for adults.
Hey folks –
I’ve been on Discord since very early 2016 and actually joined the company in 2017. Safety is one of my areas, so today’s announcement on our blog is something I’ve been pretty involved with. I’ve always cared about Discord's approach to privacy (E2EE for A/V was another of my projects here), so I figured I’d add some more context to today's news.
I can say confidently that the vast majority of people will never see age verification. I say this because we launched age assurance in the UK and Australia in 2025, and we have some pretty good data on this now. The idea here is that we can pre-identify most adults based on what we already know (not including your messages!), and that looks to get us pretty far here. No face scans, no IDs, for the vast majority of adults.
And if you are one of the smaller subset of folks that we can't definitively pre-identify, then still, you only have to do it if you're accessing age-restricted servers or channels, or changing certain settings. That's really not most users. (Altho... might be more Redditors, tbh.)
Last, I know that there is concern about privacy and data leaks. That's a real concern. The selfie system is built purely client-side, it never leaves your device, and we did that intentionally. That'll work for a bunch of users who aren't pre-identified as adults. But if you do end up in the ID bucket, then yeah, you're right that has some risk. We're doing what we can to minimize this by working with our range of partners (who are different partners than the data leak you read about), and if it's any help, we learned a lot internally from the last issue. But I get if that doesn't necessarily inspire more confidence.
Anyway, we’ll be sharing more next month as we get closer to the global roll out about the system, including the technology behind it in March. I honestly wouldn't be happy if we didn't build something good and I am excited about what we’re launching, but please let us know what you think when we share more details.
And I really appreciate everybody's feedback here today. We’re definitely reading it!
Dyson Sphere Program (an amazing factory builder game, if you haven't tried it) has similar problems -- but no circuit networks. I haven't yet figured out how to make a robust power generation system that doesn't rely on just alerting the operator that something is going wrong...
We use data services to do "data related things" that make sense to do at a central proxy layer. This may include caching/coalescing/other logic but it doesn't always, it really depends on the particular use case of that data.
For messages, we don't really cache. Coalescing gives us what we want and the hot channel buckets will end up in memory on the database, which is NVMe backed for reads anyway so the performance of a cache wouldn't add much here for this use case.
In other places, where a single user query turns into many database queries and we have to aggregate data, caching is more helpful.
Data storage is going to be multi-regional soon, but that's just from a redundancy/"data is safe in case of us-east1 failure" scenario -- we're not yet going to be actively serving live user traffic from outside of us-east1.
It's not even the most interesting metric about our systems anyway. If we're really going to look at the tech, the inflation of those metrics to deliver the service is where the work generally is in the system --
* 50k+ QPS (average) for new message inserts * 500k+ QPS when you factor in deletes, updates, etc * 3M+ QPS looking at db reads * 30M+ QPS looking at the gateway websockets (fanout of things happening to online users)
But I hear you, we're conflating some marketing metrics with technical metrics, we'll take that feedback for next time.
We currently don't intentionally block or disable third party clients or action the accounts of people who use them.
We do monitor the traffic of spammers and we build heuristics around how to identify them -- and sometimes third party clients get caught up in that. Cold comfort, I know, but it's not us trying to block/come after well-behaved third party clients.
Anyway, to OP, good luck with discordo! For one of our internal hack weeks a few years ago I tried to build an RFC1459 compliant Discord gateway... it was a fun POC, but definitely lots of rough edges because the paradigms don't exactly match up. :)
I spent a good amount of time in the late 90s writing little bots for a similar game, AT-Robots, where you write an assembly type language to program a little laser-shooting robot that could drive around, scan for enemies, etc.
http://necrobones.com/atrobots/
And my best robot: http://necrobones.com/pub/atrobots/robots/unlocked/mj6.at2
Anyway, I loved this kind of thing as a teenager. I felt it really helped me to fall in love with programming and the ability to make things happen by writing code.
Most startups fail not because they picked a suboptimal database for their usage but because they didn't build something that was good or it didn't achieve product market fit. I wouldn't worry about your database over-much in the beginning (unless it's critical to what you're doing and in that case, worry like hell, but you will probably know if that's the case.)
Many of Discord's issues with Mongo were exacerbated that we were using TokuMX which was abandoned shortly after we started using it. A few years into Discord we found ourselves with a rapidly scaling dataset and userbase that was built on top of an abandoned and not super popular third party version of MongoDB. (Funny story: at one point towards the end we realized that all of the packages had been pulled from every mirror we could find and literally the only place we could find the package files was off of some gov.uk mirror... that was a bad day. Thankfully we had the hashes and were able to validate the packages...)
FWIW, we did honestly debate moving our core user model (which was what was left in TokuMX by the end there) into a modern version of MongoDB -- some of the things we did (reverse indexes, secondary indexes, locking, etc) are much more complicated in a database like Scylla. It was tempting to just migrate the data from one "Mongo" to another and call it a day.
We didn't for a variety reasons, not least of which is keeping things simple by reducing the number of technologies you have in production (like when we chose to embrace Rust we went back and migrated nearly all of our Go systems).
Anyway, I'm pretty happy with not running MongoDB anymore, but not because MongoDB is inherently bad. It's popular for a reason!
It's still against the TOS -- my point is only that we don't specifically look for third party client users and we have no specific plans to do so.
We (Discord) moved off of MongoDB for various reasons and are quite happy about that decision but managing Cassandra/Scylla clusters is not exactly a walk in the park either.
Just want to +1 what you're saying and confirm that we are never trying to ban third party clients (that aren't self-bots). Honestly, it would be a waste of our time and basically do nothing good for Discord. But as you correctly point out, they do sometimes trip the ever-evolving heuristics we build that try to identify and mitigate spam on the platform.
If this happens to your account you can write in to our TNS team at https://dis.gd/request and they will usually take care of unbanning any accounts that get accidentally caught up in a spam heuristic. It sometimes takes a bit to investigate and respond to these kinds of requests but they generally come out right in the end.
We have a very manual anti-spam process right now that relies on humans to detect it and action it. We have a couple of very dedicated folks who end up looking every few hours, but it's not automated, and we don't have full timezone coverage.
It's definitely something I'd like to see us improve, but we've been focused on other projects (like switching from mid-90s HTML to a responsive design, which is a slow rewrite of the entire site). That said, if you have any advice on reasonably scalable ways of doing this in-house that don't involve sending our user content to a third party, I'd love to take any recommendations!
Feel free to email me, [email protected], if you would rather do that. And if not, don't worry about it, I appreciate the comment anyway :)