Doki Doki Literature Club Wiki

Hey, hold up! This page may contain a lot of spoilers.
It's recommended you play the game first before you read the article.


Mail can be accessed when you exit DDLC and go to the desktop menu.

Unlocking new emails depends on how much data the player has collected. This can be checked in the Settings menu from the game's Metaverse desktop. Once the player passes a new threshold, a notification will appear above the mail icon indicating that they've received an email, which contain important bits of lore.

Have a nice weekend![]

Have a nice weekend!

Have a nice weekend! email

This email is unlocked by collecting 55% of data.

From: Ive Laster <ilaster@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Monday, December 9, 2019 12:06 AM
Subject: Have a nice weekend!

I'm on leave the rest of the week - contact Ravi if you need to schedule server time, but I expect my jobs to run for a few days since we've collected so much data this week. How about we arrange a meeting to discuss the results when I return?

Ive Laster
Senior Engineer

Side Stories[]

Side stories

Side stories email

This email is unlocked by collecting 60% of data.

From: Rea Vorte <rvorte@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Sunday, December 8, 2019 12:06 AM
Subject: Side Stories

Thank you to everyone who worked so hard on the control simulation. I can't imagine how tedious it must have been to so delicately hide Monika's elevated permissions from her without disrupting our connections to the VM.

Just to clarify - all of the recordings labeled "Side Stories" are part of the controlled simulation, right? I'm noticing some details of the characters' lives here and there that differ a little bit from those in VM1, even trivial ones. Is it part of the butterfly effect from some of Monika's fundamental changes, or is it a result of her just messing around with the other characters in VM1 as her own experiment (or for fun)?

So if I'm keeping track, we have what, like 5 different universes in total? With 3 or 4 of them created and then destroyed by Monika, of course. It's funny because I keep wanting to speculate on which one is the "real" universe but in reality, they all are. As real as ours is, anyway.

Rea Vorte
System Administrator

Character discrepancy[]

Character discrepancy

Character discrepancy email

This email is unlocked by collecting 65% of data.

From: Lib Musi <lmusi@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Saturday, December 7, 2019 12:06 AM
Subject: Character discrepancy

Having run the control simulation for a while, it's evident that a certain "character" is missing from any mention or appearance. This makes me speculate that Monika's meddling is less clumsy than we think, because she would have had to manufacture this "character" herself as a way of forcing interaction between her and the user. Could that be why the "character" has such limited and dissonant personality traits? Or am I reading too much into this?

I'll open an issue to start tracking info and observations on the anomaly of this "character" appearing.

Lib Musi



omg email

This email is unlocked by collecting 70% of data.

From: Ive Laster <ilaster@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Friday, December 6, 2019 12:06 AM
Subject: omg

Okay, who's responsible for creating a Twitter account for Monika?

I think it's hilarious, but for god's sake don't tell Paula. HAHAHA. It would get 4-0-4'd in a microsecond.

Are you just relaying her tweets manually, or did you code some kind of pass-through layer to automate it? Based on the contents of the tweets (eg. not screaming for help) I assume they're coming from the control simulation?

Ive Laster
Senior Engineer

Staying focused on our goals[]

Staying focused on our goals

Staying focused on our goals email

This email is unlocked by collecting 75% of data.

From: Paula Miner <pminer@mes.local
To: Untitled Mail Group (DO NOT USE)
Date: Thursday, December 5, 2019 12:06 AM
Subject: Staying focused on our goals

As a reminder to help guide our data collection, any analysis performed should be focused on answering some of these main questions:

- How does granting elevated access to the VM affect a person's values and goals?

- How does someone effectively navigate and experiment with their ability to change the contents of their VM?

- How is elevated access being weaponized?

- What actions and values most contribute to the destruction of the universe?

- Most importantly, how might your observations apply to our universe?

- Bonus: How can we present this to the upper management as an operation that benefits the company?

Unrelated note: Whoever changed the color scheme of the desktop to pink, can you please change it back? It's unprofessional and it runs the risk of drawing eyes.

Paula Miner
Project Manager

Re: Ethics[]

Re- Ethics

Re: Ethics email

This email is unlocked by collecting 80% of data.

From: Paula Miner <pminer@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Wednesday, December 4, 2019 12:06 AM
Subject: Re: Ethics

Simply put, it's not our job to arbitrarily decide upon some code of ethics just because we're the first ones to do this (to our knowledge). That's the government's job to figure out, long after we've made enough headway for it to no longer apply to us.

It's fundamentally flawed to apply ethical reasoning to this anyway, because humanity's code of ethics is based upon nothing more than our knowledge and understanding of life forms similar to ourselves. We don't have ethics for killing bacteria or plants - only for creatures that we can convincingly project our emotions onto. The "humans" in our VMs operate completely differently from us on a fundamental level, and therefore should not be taken any more seriously than a machine that's programmed to print "I feel sad".

We're engineers, not philosophers.

Paula Miner
Project Manager

Issues caused by unprotected memory[]

Issues caused by unprotected memory

Issues caused by unprotected memory email

This email is unlocked by collecting 85% of data.

From: Ravi Raso <rraso@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Tuesday, December 3, 2019 12:06 AM
Subject: Issues caused by unprotected memory

Has anyone evaluated the side effects that might be caused by sharing a memory pool between multiple VMs, rather then allocating them separately? I'm looking at some of the files VM1 is generating, and I'm finding some information that *definitely* shouldn't be there. I haven't seen any evidence that this is actually affecting the inside of the VM itself, so I don't think this is a priority, but it's definitely worth noting.

My best guess is that memory being freed from VM2 isn't getting zeroed out, which technically gives VM1 access to it. All the info I have will go into the issue tracker, but I wanted to check if anyone else already noticed something along these lines.

Ravi Raso
System Engineer

Binary data in VM2?[]

Binary Data in VM2 email

Binary data in VM2? email

This email is unlocked by collecting 90% of data.

From: Ro Teether <rteether@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Monday, December 2, 2019 12:06 AM
Subject: Binary data in VM2?

I've made some new headway with VM2. Don't get too excited, it's still impossible to establish any stable connection.

But it occurred to me that I could at least run a memory dump through some pattern analysis routines to see if we can decipher any digital data from their VM. I didn't want to hog all the server time on a hunch, but I have some preliminary results that indicate the presence of binary computer systems. Based on this, I'm going to schedule three days of server time next week to isolate any chunks of memory that appear to be binary data. If successful, we'll definitely be able to find some encoded text and get our first tiny glimpse of VM2.

Don't mind me though, just keep going nuts on VM1 and hopefully I'll have more to share soon!

Ro Teether
Systems Engineer

Let's move on[]

Lets move on email

Let's move on email

This email is unlocking by collecting 100% of data.

From: Paula Miner <pminer@mes.local>
To: Untitled Mail Group (DO NOT USE)
Date: Sunday, December 1, 2019 12:06 AM
Subject: Let's move on

We need to have a meeting about shifting our focus a little bit. We've reset VM 1 how many times now? For real, we've definitely collected as much data as we can from it at this point. We just need to work with what we have and try to increase the stability of our connection to VM2. We've obviously gotten spoiled by the ease of access that VM1 offers us, but it's just unrealistic for someone in real life to be granted a level of elevation even close to "Monitor Kernel Access". If we can't establish a stable connection to VM2, then how can we expect to get anywhere when the same scenario inevitably occurs to our own universe?

Anyway - thanks to Ro's work, we were able to acquire a few rudimentary logs. I have an idea on how to increase connection stability to VM2 while maintaining weak hypervisor access to everyone inside on an individual basis. Ironically, it has to do with something that they're building in their own VM. I'll go into detail in a more formal report, but some of the log files indicate attempts of theirs to pool together the access potential of multiple individuals into a single parallel unit. It sounds ridiculous, but if they actually get somewhere with it, then we might have a solid entry point that doesn't heavily intrude upon the VM.

I'm going to spin up a read-only hypervisor that we can use to test different ideas like this. The elevation level will be set to "Monitor Adjacent Runtime-Level Access". The VM will just be named "TEST VM" for now, although the parallel-access unit they're building in the VM seems to be called "Project Libitina", according to the few logs we have. We can change the name once we actually get a decent picture of it.

Paula Miner
Project Manager