Frostcord

Frostcord is Frostforge’s fork of Sharkord, an MIT-licensed platform whose repository starts five months before my first commit. What I added is the product around it: the desktop application, the licence server and the provisioning API, written from scratch, plus roughly half of the server and web client, the release engineering and the legal surface. The problem it answers was already the right one.

Teams that cannot put their internal conversations on a third-party platform - regulated industries, public bodies, anyone with a data residency requirement - are left choosing between self-hosted tools that feel a decade old and SaaS they are not allowed to use.

The self-hosted options that do exist tend to fail at installation. They assume an operator who is comfortable with a reverse proxy, a database, a TURN server and a certificate chain. That operator does not exist at a 20-person company.

The product documentation runs to 184 articles across fifteen sections, and exactly fourteen of those articles cover self-hosting. The other 170 are the part people use: messaging, voice and video, direct messages, servers and channels, moderation, security and privacy, friends and presence, plugins, user settings, and one section each for the web, desktop, mobile and mobile-web clients.

Underneath: an HTTP server for auth and uploads, a WebSocket layer over tRPC carrying 230 procedures behind permission middleware - 114 mutations, 66 queries and 50 live subscriptions, a MediaSoup SFU, SQLite behind Drizzle that migrates itself on startup, a pub/sub layer, a plugin runtime, and cron jobs for cleanup, expiring messages, scheduled delivery, checkpoints and backups.

A Tiptap composer with Markdown, syntax-highlighted code blocks, spoilers and mentions. Inline replies, threads, edit history that keeps every previous version, bookmarks collected across all channels, and search over content and filenames.

Scheduled messages are delivered server-side, so they arrive whether or not the author is still connected. Auto-deletion expires messages after a day, a week or a month through a job that runs every minute. Reactions cover the full Unicode set plus custom server emoji.

WebRTC through a MediaSoup SFU rather than a mesh, so a call does not degrade with the fourth participant. 1080p60 by default, screen sharing, webcam, per-user volume, and a transport cap so one client cannot saturate the link.

Noise suppression runs client-side through DTLN and RNNoise. VP9, VP8, H.264 and AV1 for video, Opus for audio.

Direct messages can be end-to-end encrypted by mutual consent: X25519 ECDH for key agreement, AES-256-GCM for message bodies, HKDF-SHA256 for derivation, and a per-conversation group key that rotates its epoch whenever membership changes. If a current key is unavailable the client refuses to send rather than falling back to plaintext.

Key backup is done in the browser with PBKDF2 at 600,000 iterations before anything is uploaded, so the server holds a blob it cannot open. A 60-digit safety number derived from both public keys lets two people verify out of band that nobody is in the middle, and it changes if a key does.

The interesting part is the documentation of what this does not protect. Attachments are not encrypted - the server sees their bytes, names and sizes, and the interface says so. The epoch key gives no per-message forward secrecy. Sender attribution stays server metadata rather than a per-message signature. A compromised device is outside the boundary entirely. All of that is written down, because an encrypted-messaging feature whose limits are undocumented is worse than one that makes no claim at all.

A chat platform is not a product until somebody can buy one. The licence server and the provisioning API are the part of this that is mine outright - about eleven thousand lines with their own test suites - and they are what turns a repository into an instance a customer pays for.

Licences are validated against a signed response, not a boolean. Each answer carries the plan, the expiry, the seat count and a machine binding, signed with a key the server refuses to load unless it is a regular file under 64 KB opened without following symlinks, and unless the private half is mode 0600. The response is bound to the request by nonce and timestamp with a five-minute skew window, so a captured answer cannot be replayed at another machine later. The heartbeat is signed the same way.

Provisioning is one call. It reserves a slot under an operation lock, builds a Proxmox container, installs packages behind temporary firewall rules, hardens the container, injects the licence, writes a Caddy route, creates the DNS record and waits for it to go proxied, assigns a WebRTC port, waits on a health check, and registers the instance for high availability - with ownership markers so it can never adopt a container it did not create, and a removal path that undoes all of it in the right order.

Roles carry 35 granular permissions with per-channel overrides, custom colours, hoisting and drag-and-drop ordering. Moderation covers timeouts, kicks, bans, slowmode, channel archiving, bulk deletion across every channel and DM, and device-fingerprint checks against ban evasion. An audit log records thirty-eight kinds of event.

Security is layered, never assumed: TOTP two-factor with rate limiting, email verification, Turnstile, VPN and proxy blocking, geoblocking, Argon2 password hashing, signed updates the binary verifies against itself, and an admin token required before the first account can be created.

Four client targets from one monorepo: the web client, an Electron desktop app with multi-server folders, a tray, deep links and an integrity check, and native Android and iOS builds through Capacitor. Nine interface languages.

All of that arrives as one executable. The operator downloads a file, runs it and opens a browser - no separate front-end deployment, no container orchestration, no database to provision, no reverse proxy to reason about before the first message is sent.

The single component deliberately kept outside that process is the plugin runtime: each plugin runs as its own subprocess and talks to the server over IPC.