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, mark@dreamwidth.org, if you would rather do that. And if not, don't worry about it, I appreciate the comment anyway :)

Pretty cool to see my project hit the front page of HN, but definitely a bit of a /shrug moment on the subject itself. "Facebook gonna Facebook" I think is approximately how we feel about this.

I know here on HN we're used to hearing stories about scrappy startups trying to carve a piece of the pie big enough to exit on, but that is pretty much the exact opposite of what Dreamwidth is. Our motivations are very different, so this FB block is mostly a curiosity to us.

Dreamwidth is a small, neighborhood corner store kind of site. We're run by a couple of dedicated part-time staff (who have other jobs/responsibilities in life -- I personally work for Discord!) and a cadre of amazing volunteers who donate of their time and energy to make a nice little corner of the Internet that isn't driven by the cycle of VC and growth and user monetization.

We do not have any goals around growth, we don't advertise, and we ultimately don't care that much what the other platforms do. Our goal is to give people a stable home where they don't have to worry about their data being sold, their writing being monetized. Users choose to pay us for a few more advanced features (like full text search), and we support ourselves entirely off of that.

We are home to a large group of online roleplayers, Hugo Award winning fiction writers, Linux kernel developers, parents, security researchers, artists, activists, recipe bloggers, educators, and everything in between and around the edges who would rather work with a service owned and run by people who are motivated by something other than get-big-and-exit. Large communities of online roleplayers who get together and build whole worlds on Dreamwidth, who tell stories together. I'm constantly impressed by the creativity of our community.

Anyway, it's super cool to see Dreamwidth on the home page here. It's been my side project for over a decade now, and I'm quite proud of it. Even if modernizing a 20+ year old Perl project is a hellish undertaking at the best of times... but we keep going. :)

The Fortnite Official server has exceeded 100,000 concurrent users, Discord itself is way past that 5M concurrent number, we're now using Rust in certain places to make Elixir go faster, we've built a general purpose replacement to Process.monitor that scales a whole truckload more that we're open sourcing next week at Code BEAM SF... the list goes on.

There's a lot of fun stuff going on to try to make this system even more efficient and reliable, there's a lot to do still. We run everything on a very small engineering team (there are 4 fulltime engineers on the core infrastructure, only about 40 engineers in the whole company) and we're always looking for a few more. Feel free to reach out to me (zorkian#0001 on Discord) if this blog post sounds up your alley!

Comments URL: https://news.ycombinator.com/item?id=4242609

Points: 19

# Comments: 11