What protects your data, and what does not exist yet

Direct messages and group direct messages are end-to-end encrypted with MLS, the IETF standard published as RFC 9420, implemented with OpenMLS and compiled once in Rust so every client runs identical cryptographic code. Each device is a separate member of the group, so adding one is visible and removing one re-keys the conversation.

• One key per device, never one per account
• Forward secrecy and post-compromise security from the protocol, not from policy
• The server implements the delivery service and performs no MLS cryptography
• Device cross-signing and safety numbers for out-of-band verification
• Encrypted key backup so a lost device is not lost history
• Everything in transit over TLS; managed content encrypted at rest

Several organisations share one installation and no row crosses between them. The organisation is asserted at one choke point rather than remembered at each call site, and a request for another organisation’s object is answered with a not-found rather than a forbidden, because a forbidden confirms that the object exists.

• A probe suite generated from the OpenAPI document drives every operation across the boundary
• 203 operations driven, 203 refused — and the suite fails the build if that regresses
• Files and audit records carry the organisation they belong to
• Every metric and log line is labelled with the organisation id, never its name

Permissions are a bitmask evaluated in the data layer, so a capability that is not granted is not merely hidden in the interface. An organisation names its own roles over that bitmask, and a role can never carry a permission its author does not hold, which closes the usual privilege-escalation path.

• Exactly one owner per organisation, transferable, enforced by a database constraint
• Administrators cannot grant themselves billing authority; only the owner holds it
• Permission overwrites per category, channel and board
• Field-level permission resolution in the People module across seven roles
• Bot accounts and personal access tokens scoped to named operations

The controls that matter after launch rather than at signature. Rate limits are applied per organisation and scaled by seat count, with each member capped at a share of the whole, so one runaway integration cannot exhaust the budget for everybody else.

• Per-organisation rate limits, with per-member caps
• Storage accounting and per-organisation usage records
• Retention configurable per organisation; the default keeps data
• Full organisation data export
• Audit log of administrative action, scoped to the organisation
• Uploads scanned for malware before they can be opened
• Link previews fetched behind SSRF protection, never from your browser

The platform control plane — the part our operators use — is a separate identity with its own sessions, its own audit log and a deliberately blind interface: it can list organisations, suspend one, schedule a deletion and run a purge, and it cannot read content. That is enforced by a build check, not by a policy document: the control-plane package is not permitted to import anything that can read your content, and continuous integration fails if that ever changes.

• Operator accounts are separate identities with mandatory multi-factor authentication
• The control plane sees metadata: organisations, lifecycle, counts
• A build check forbids the control plane from importing content-reading code
• There is no impersonation feature and no silent support access
• Operator action is written to a separate platform audit log

Every runtime dependency is open source under an OSI-approved licence, and that is enforced by a licence gate in continuous integration that fails the build when a dependency relicenses. Several otherwise obvious components are absent from the stack for exactly this reason.

• Zero non-OSI runtime dependencies, checked on every build
• Dependencies updated weekly rather than quarterly
• PostgreSQL, NATS and LiveKit underneath — components you can audit yourself