Keeping DM secrets separate from player-visible notes

Running a game means maintaining two views of the same world: what is true, and what the party currently believes. Almost every tool a DM might use assumes there is only one view, which is why most groups end up with an improvised arrangement of separate documents, colour-coded text, and a habit of never sharing your screen.

It is worth being precise about where secrets actually leak from, because the answer is rarely the one people plan for.

Where secrets actually leak

Screen sharing. Overwhelmingly the most common. Playing over a call and sharing a map, a stat block, or a note, with the rest of your notes one tab away. No amount of careful file organisation survives a mis-click.

Scroll-past. The document is shared and the secret is further down the same page. Someone scrolls looking for something else.

Search. The tool has a search box, the hidden content is in the same workspace, and searching for a name surfaces a preview of a note the player was never meant to open.

Hidden-but-sent. The subtle one. Content is delivered to the browser and merely not displayed — collapsed, styled invisible, or filtered client-side. It is one inspector panel away, and it is how the majority of "private" content in shared tools actually works.

Drift. Two documents, sync abandoned six weeks ago, and one of them now contains something you assumed was in the other.

Notice that only the first two are about DM carelessness. The rest are properties of the tool.

Filtering has to happen before the content is sent

This is the part worth insisting on. If secret content reaches a player's device at all, "secret" is a display convention rather than a guarantee.

The right behaviour is that the server decides what a given user is allowed to read and sends only that. In Dungeon Ledger a player's browser never receives the content of a note they aren't permitted to read — there is no hidden element, nothing in the page source, nothing in the search index for that user.

The same rule needs to hold for anything built on top of the notes. The campaign assistant, for example, answers questions using only the notes the person asking can already read, so a player cannot ask a clever question and get an answer assembled from DM-only material. Permission checks belong at the retrieval layer, not in an instruction asking a model to please not tell anyone.

Keep secrets next to what they are about

The instinct is to put all secrets in one place — a single "DM notes" document. It is the wrong shape, for the same reason a single "misc" folder is.

A secret is about something: this NPC's real allegiance, what is actually in the vault, why the town is empty. Filed together in a separate document, secrets lose their attachment to the thing they explain, and you end up scrolling a long file looking for the paragraph about the harbourmaster.

Better: the secret lives beside the note it concerns, linked to the same people and places, with its visibility set to DM-only. Same structure, same links, different audience. When you open the location, its secrets are right there; when a player opens it, they are not.

Plan the reveal as a state change

If secrets are separate documents, revealing one is a copy-paste you have to remember to do — and the copy usually loses the links and context that made it useful.

If visibility is a setting on the note, revealing is changing one field. The note keeps its links, its history and its place in the graph; it simply becomes readable. That makes it viable to write the reveal properly in advance, at the moment you have the idea, rather than improvising it at the table.

A useful habit: when you write a secret, write the version the players will eventually read, not just the shorthand you need to run it. Future-you is grateful, and the reveal lands better for being composed rather than paraphrased.

Player privacy counts too

One thing tools built around "DM secrets" consistently miss: players want private notes as well.

Someone planning a betrayal, working out a theory, or writing character interiority they are not ready to share needs somewhere to put it that the rest of the party cannot read — and that the DM does not necessarily need to read either. A model where the only axis is "DM sees everything, players see the shared stuff" fails that.

Per-note visibility with a genuine private option covers it, and tends to produce a better-documented campaign: people write more when they are not writing for an audience.