Rocket.Chat

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 the team chat with customer conversations in it, replacing a paid Rocket.Chat tier: internal channels and the inbox in one place.

Read this first: Rocket.Chat is open source and self-hosting it is a real answer — the fee buys hosting, support and published mobile apps with push. Build this when the team is small and the requirement is specific, and note the one gap that money does not close cheaply: mobile push needs a relay registered with the platform.

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 delivery, with a polling fallback
- Caddy in front

THE IDEA
- Two things in one interface: the team talking to each other, and the team talking to customers
- The value is that they are the same interface, so a support question becomes an internal thread without anybody copying anything or switching windows
- Keep them clearly distinguishable, though: a message to a colleague and a message to a customer look different and are never confusable. Sending an internal note to a customer is the failure this design has to prevent above all

THE DATA MODEL
- users, channels, memberships, messages, reactions, mentions — the ordinary chat shape, with read state per user per channel
- conversations: id, contact_id, channel_kind, subject, status, assignee_id, team_id, priority, first_response_at, resolved_at, linked_channel_id — a customer conversation, optionally attached to an internal channel
- contacts: id, email, name, phone, external_id, traits_json, first_seen_at
- conversation_messages: id, conversation_id, direction, author_kind, author_id, body_md, body_html, is_private, delivered_at, created_at — is_private is the internal note, and it is rendered so differently it cannot be mistaken
- routing_rules: id, kind, match_json, team_id, position
- events: id, conversation_id, kind, actor, at — append-only, and the basis of every metric

CHANNELS IN
- Web chat through a widget on your own site, optionally with a signed identity token from your product
- Email, with proper MIME parsing, threading by Message-ID, In-Reply-To and References, quoted history stripped for display but kept in full, and bounces and automatic replies detected rather than turned into conversations
- Messaging platforms only where an application can actually be approved — check that before promising it, because it is administrative rather than technical
- Each channel is an adapter with one interface: receive, send, mark delivered, describe limits. The rest of the system never knows which channel it is talking to

ROUTING
- Rules by channel, keyword, contact trait or time of day, assigning to a team
- Round-robin within a team, respecting availability, with a manual override
- Unassigned is a visible state with an age, because the conversation nobody owns is the one that goes unanswered for two days
- Escalation when a first response time is about to breach

DELIVERY
- Message written to the database first, then broadcast. Never the other way round
- Every message carries a client-generated identifier, so a resend after a dropped connection deduplicates rather than doubling
- On reconnect the client asks for everything since its last known message and receives it in order. That endpoint is what makes chat feel reliable on a train
- Presence in memory, never stored

THE INTERNAL SIDE
- Channels public and private, threads on a root message, read state per channel and per thread
- Mentions resolved at write time so the list is a lookup
- Keyboard for everything: next unread, reply, edit last, search
- Search with FTS5, respecting permissions inside the query, across both internal messages and customer conversations — with the distinction preserved in the results

NOTIFICATIONS
- Per-channel levels and a mute with an end time
- Desktop notifications and email digests for what was missed
- Mobile push is the honest gap: a phone only accepts notifications from a service registered with the platform's push provider, which means either somebody else's relay or your own registered application. Say so in the README, and send only 'you have a message' through it rather than the content

METRICS
- First response time, resolution time, conversations per agent, by day and hour, computed at query time from events
- Never stored totals

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL, IMAP_URL, WIDGET_JWT_SECRET, HASH_SALT
- Migrations on boot, each once
- The WebSocket layer in its own process
- Nightly backup off the machine, restore script — this holds both the team's memory and every customer conversation
- Health endpoint checking both mail directions

WHAT MATTERS MOST
The private-note distinction and email threading. Make an internal note impossible to send to a customer by accident, and thread inbound mail by Message-ID rather than subject. Those two failures are the ones customers see, and both are unrecoverable once they happen.

Give me the repository, the widget, one messaging adapter, migrations, .env.example, and a README with deploy steps behind Caddy, the mail DNS records and the push situation stated.