Covert Mission

Covert Mission is a coordination app for small groups — a squad, a team, a handful of people trying to agree on something while looking at the same picture. It is running, it is in use, and it is invite-only, so there is no link on this page to send you to.

It exists because of a specific, boring frustration. Five people in a chat window are five people in five different places in the scrollback. Somebody pastes a map. Two people look at it, one is still reading the thing from four minutes ago, and one is scrolled up entirely. Then somebody pastes a second map, and now “the map” is ambiguous. The conversation is all there, in order, and it is still nearly useless twenty minutes later, because what was decided is spread across sixty messages with no marker saying which of them mattered.

One thing is on the Stage

So the middle of the screen is a Stage, and exactly one thing is on it. An image, a link, a video, a dice table, a poll. Putting something on the Stage is the primary gesture in the app — /img, /url, /stage, /poll — rather than something you do by pasting into a stream and hoping.

The point is not that content is bigger. It is that “look at this” stops being a request. There is no version of the room where you and I are discussing different maps, because there is only one Stage and we are both pointed at it.

Threads are made by the Stage, not by people

This is the part that turned out to matter most, and it was not the plan at the start.

Every time the Stage changes, a thread opens against it, bookmarking exactly what was on the Stage at that moment. You cannot create a thread by hand and nobody has to remember to. The result is that a session self-organises into “the bit where we argued about the approach”, “the bit about the patch notes”, “the bit where we fixed the timing” — with the artefact each argument was about attached to it.

Threading in chat normally asks people to do filing while they are trying to have a conversation, which is why it mostly doesn’t happen. Here the filing is a side effect of the thing everyone wanted to do anyway.

Sessions close themselves, and can be replayed

Rooms are long-lived; the useful unit is an evening. Sessions are created automatically after an hour of quiet, so the record breaks along the seams where the group actually stopped rather than wherever someone thought to draw a line.

Anything that has been recorded can be played back. Catch-up mode replays a session in order — messages arriving as they arrived, and the Stage changing as it changed — so someone joining late watches what happened instead of reading upwards through it. That falls out of storing the session as an ordered event log rather than as a table of messages, which was worth the extra work on its own.

How it is built

Nuxt 3 serves the app and the API. A separate Node WebSocket server owns the real-time side, with Redis underneath it for pub/sub between connections and for presence. Postgres holds everything durable — users, rooms, sessions, threads, messages — and threads carry the Stage snapshot that created them in a JSONB column, which is what makes a thread meaningful on its own months later.

It runs on a single VPS, deployed with Ansible and kept alive by PM2. That is a deliberate ceiling: it is a tool for small groups, and the number of people who will ever be in one room at once is small enough that the interesting problems are all in the design rather than the scaling.

The vocabulary is configurable, which started as a joke and stayed because it was useful. Stage, Thread, Session and Roster are all environment variables, so the same app can present as a mission room or as an incident channel without a fork.

Where it is

In use, and still moving. The things that have gone in most recently are the ones a real group asked for after a real evening of using it — pinned links, ready checks, push notifications, dice — rather than anything from the original specification.