The commitment

If our servers are stolen, the thief gets nothing they can read. These are the load-bearing rules every change is reviewed against — architecture, not policy:

• ✓Our servers hold sealed boxes and the plumbing to deliver them — never a key that opens anything. Messages, names, and files are locked on your device before they leave it.
• ✓Keys live only on your devices. Every conversation is sealed with its own key, handed only to its members; the server stores wrapped copies it cannot open.
• ✓Every space is an island — its own database, its own keys, no shared pool of user data, no cross-user state anywhere, and no protocol tying spaces together.
• ✓Invite links keep their secret in the URL fragment — the part a browser never sends to any server.
• ✓Credentials are never keys. Admin tokens manage the roster; push credentials authorize delivery of sealed bytes. Neither opens a single message.
• ✓Bot code never runs inside the server. Bots live on machines their operator controls, as ordinary members — compromising our server yields no bot keys.
• ✓No personal data in our stores — no emails, no per-user analytics. Customer identity for paid spaces lives with the payment processor; we hold an opaque pointer and an entitlement flag.

Dependency hygiene

Counted, not named: the product that ships is a single Go binary (the web client is plain JavaScript it serves — zero runtime npm packages; npm is test tooling only). Each release build is scanned with govulncheck against the exact binary the fleet runs. A finding publishes here as a count until it’s patched — naming an unpatched hole would hand attackers a map.

Dependency scan pending. No scan has been published for the current build (or the feed didn’t load). Shown honestly rather than assumed clean — the architecture and hardening facts on this page hold regardless.

Hardening

The posture, not the address: how the serving machines are run. Facts only — nothing here locates a box.

• ✓Firewall is default-deny. Inbound is web traffic and administration (SSH) only; everything else is refused.
• ✓SSH is key-only. Password login is disabled outright.
• ✓OS security updates apply automatically (unattended upgrades).
• ✓Services run as an unprivileged user in a systemd sandbox — read-only system, no privilege escalation, memory-capped.
• ✓TLS everywhere. Every space is served over HTTPS with automatically issued and renewed certificates.
• ✓Member content at rest is ciphertext. A stolen disk — or a stolen backup — is a pile of locked boxes.

Known edges, on purpose

What we don’t protect, and why: the deliberate tradeoffs, named plainly. These are disclosed design choices, not bugs.

• ◆Link previews: when someone posts a link, the server fetches that URL to build the preview card — so it briefly sees URLs (never message text). The price of previews; gateable behind a setting later.
• ◆GIF search: your browser queries Giphy directly, so Giphy sees your search terms and network address; our server sees nothing. The chosen GIF is sealed to the conversation like any attachment.
• ◆Branding is plaintext: a space’s name, optional photo, and description are admin-set and must render before a joiner holds any key — so they are deliberately not encrypted. Everything members write still is.
• ◆Bots are members: a bot you add runs on a machine its operator controls, and that machine can read exactly the conversations the bot is in — never anything else. Scoped, disclosed, and removable like any member.
• ◆A content-blind store can’t scan content: because we can’t read anything, no server-side abuse filter is possible — a store we can’t open is also a dead drop we can’t inspect. Abuse handling is structural instead: invite-gated rosters, admin removal, and members’ own judgement. We accept that trade with open eyes.