Mattermost

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 I actually need instead of a paid Mattermost tier: channels, threads and search, with retention and single sign-on.

Read this first: Mattermost is open source and the free version is genuinely capable — the fee buys compliance export, retention policies, single sign-on and support. Build this when the team is small and specific, and note the one part that is not free either way: mobile push needs a relay, because a phone will only accept a notification from a service 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 for search
- WebSockets for delivery, with a polling fallback
- Caddy in front

THE DATA MODEL
- users: id, email, username, display_name, avatar_path, status, timezone, is_active, created_at, last_seen_at
- channels: id, kind, name, slug, purpose, header, created_by, is_archived, created_at — public, private, or a direct message
- memberships: channel_id, user_id, role, joined_at, last_read_message_id, notify_level, muted_until
- messages: id, channel_id, user_id, parent_id, body_md, body_html, edited_at, deleted_at, created_at, pinned_at
- attachments: id, message_id, path, sha256, mime, bytes, width, height, thumb_path
- reactions: message_id, user_id, emoji
- mentions: message_id, user_id, kind — resolved at write time, so the mention list is a lookup rather than a scan
- read state per user per channel, which is what makes chat usable
- retention_policies: id, scope, scope_id, keep_days, applies_to — messages, files, or both
- audit: id, actor_id, action, target, at — append-only

DELIVERY
- WebSocket per connected client, subscribed to their channels
- A message is written to the database first, then broadcast. Never the other way round, or a client sees something that does not exist after a crash
- Every message carries a client-generated identifier so a resend after a dropped connection is deduplicated, and the sender's own optimistic copy is reconciled rather than duplicated
- On reconnect the client asks for everything since its last known message id, and gets it in order. That single endpoint is what makes a chat feel reliable on a train
- Presence in memory, never in the database — it changes constantly and is worthless a second later

THREADS AND READING
- Replies form a thread on a root message; the channel shows a compact summary with the reply count and the participants
- Read state per channel and per thread, so a thread you are following is unread while the channel is not
- Unread separators, jump to the first unread, and mark all read — the three controls people use every day
- Keyboard for everything: next channel, next unread, reply, edit last, search

SEARCH
- FTS5 over message bodies, with filters by channel, author, date, and whether it has a file
- Search results must respect permissions, checked in the query rather than filtered afterwards
- Search inside a thread, and jump to the message in context

NOTIFICATIONS
- Levels per channel: all messages, mentions only, nothing, with a mute that has an end time
- Desktop notifications through the browser, email digests for what was missed, and a quiet-hours setting per person in their own zone
- Mobile push is the honest gap. A phone accepts notifications only from a service registered with the platform's push provider, which means either a relay somebody else runs or registering your own application. Say so in the README, and note that sending the message content through a relay is a privacy decision — send only 'you have a message' and let the app fetch it

RETENTION AND EXPORT
- A policy per channel or globally: keep messages and files for N days, then delete
- Deletion is real, including attachments on disk, and it is recorded that it happened
- Export a channel or the whole workspace as JSON with the attachments, in one command — for compliance, and because being able to leave is a property worth having
- Legal hold on a channel, exempting it from retention, with the hold logged

ACCESS
- Single sign-on through OIDC, which is the only sane answer for staff accounts, with magic links as a fallback
- Sessions revocable centrally, with a device list per user
- Private channels genuinely private: membership checked on every read path, default deny
- Guest accounts limited to named channels

FILES
- Uploads streamed to disk, type from content, size capped, stored by hash outside the web root
- Served through a permission check, never a guessable path
- Images thumbnailed, EXIF stripped

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL, HASH_SALT
- Migrations on boot, each once
- The WebSocket layer in its own process, so a busy channel cannot slow the rest
- Nightly backup off the machine, restore script — this holds the team's institutional memory
- Health endpoint

WHAT MATTERS MOST
Reconnection and read state. Build the since-message-id endpoint and per-channel read tracking first, then use it on a bad connection for a week. Chat lives or dies on whether you can trust that you have seen everything, and every other feature is downstream of that.

Give me the repository, migrations, .env.example, a seed workspace, and a README with deploy steps behind Caddy and the push notification situation stated plainly.