Missive

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a shared inbox with the discussion inside it, replacing Missive — and know what makes this ALMOST.

**The idea worth copying is chat attached to the thread.** Deciding what to reply happens somewhere; when that somewhere is a separate application, the decision and the record are permanently apart. What is hard is real-time delivery and threading that survives real mail.

STACK
- Node 20+ with Fastify, server-rendered HTML with vanilla JS for the live parts
- SQLite through better-sqlite3, WAL mode, with FTS5
- WebSockets for the chat, with a polling fallback
- Caddy in front

THE DATA MODEL
- conversations: id, mailbox_id, subject, status, assignee_id, created_at
- messages: id, conversation_id, direction, message_id, in_reply_to, references_json, from_address, body_html, body_stripped, created_at
- comments: id, conversation_id, author_id, body_md, created_at — **the chat, on the same thread as the mail, and impossible to send outward**
- drafts: id, conversation_id, body, updated_by, updated_at, version — shared, with a version so two people do not overwrite each other
- viewers: conversation_id, user_id, at, is_typing — in memory

THREADING, WHICH IS THE FIRST HARD PART
- Match on Message-ID, then In-Reply-To, then References. Only then subject plus participants, and **never subject alone** — two customers writing 'Re: my order' must not become one conversation
- Strip quoted history for display, keep the whole message, with a fixture per mail client because they all quote differently
- Detect automatic replies and bounces from their headers and never turn them into conversations

THE COMMENT THAT MUST NEVER GO OUT
- A comment and a reply are different objects, rendered so differently they cannot be confused, and the send path physically cannot take a comment
- That mistake is seen by the person it is about and no apology fixes it. Make it structurally impossible rather than carefully avoided

COLLABORATIVE DRAFTING
- A version per draft; a save against a stale version is rejected and the newer text shown, never silently overwritten
- Who is typing, shown live
- Full simultaneous editing needs a conflict-free replicated data type library — worth it only if two people genuinely write one reply at once, which is rarer than the feature list suggests

DELIVERY
- Comments written to the database first, then broadcast. Never the other way round
- A client-generated identifier on each, so a resend after a dropped connection deduplicates
- On reconnect, everything since the last known id, in order

AND THE REST
- Assignment, snooze with a wake time, canned replies by shortcut, and search with FTS5 respecting permissions inside the query
- Send from your own domain with SPF, DKIM and DMARC; monitor the age of the newest inbound message, because an inbox that quietly stops receiving is the worst failure here

WHAT MATTERS MOST
Threading, and a comment that cannot be sent. The first decides whether the inbox is usable; the second decides whether you keep the customer.