SECURE CHAT / TECHNICAL SELF REVIEW
Keys in your browser. MLS end-to-end encryption. One shared deadline, up to 24 hours. No account. No server archive.
Open protocol. Open source. Explore the architecture and the checks behind it.
Want to audit the implementation or request review material? Telegram DM ↗
Keep your IP from the server: Tor Browser / .onion ↗
Keys remain here
Ciphertext and metadata
Authenticated text only
PROTOCOL AND LIFECYCLE
The browser generates a separate chat identity with Ed25519 signatures and an MLS KeyPackage. A basic MLS credential contains SHA-256 of its signing public key. Profiles bind the nickname to that key with a signature scoped to this conversation and its deadline. The browser checks case-insensitive nickname uniqueness; the full fingerprint identifies the temporary key, not a real person.
A link contains a random 256-bit secret, a random conversation ID, the founding signing key and the shared expiry after #. This fragment is removed from the current history entry. HKDF-SHA-256 derives separate bootstrap-encryption and transport-capability keys. The original secret is never submitted to the relay. The founder signs the encrypted chat name. The anchor gives no administrative privileges. Every roster carries signed admission certificates chained to this founding key; an invitation holder cannot replace the group with an unrelated founder.
A separate browser-generated P-256 transport key signs a single-use, 60-second challenge bound to the origin, conversation, expiry, public transport key, capability hash and creation manifest. The relay consumes it before verification, then issues a 256-bit bearer token. A guest submits an encrypted, signed one-time MLS KeyPackage. An online participant automatically admits it through an MLS Add commit and an HPKE-protected Welcome. New guests receive future messages, without earlier history. All participants have the same capabilities. The full KeyPackage signature and MLS proposal are validated before taking a write lease. Invalid requests are rejected without closing existing participants; abandoned reservations expire after two minutes. If no surviving admitted session exists, the relay rejects new admission explicitly; when all remaining sessions have stopped polling, sign-in asks the guest to wait for an original tab to reconnect.
The pinned implementation is ts-mls 1.6.4, using RFC 9420 suite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519: X25519, AES-128-GCM, SHA-256 and Ed25519. MLS authenticates the group transcript and derives separate message generations. An additional application signature binds the sender fingerprint, message ID, text, epoch, conversation and deadline. Clients verify everything before rendering plain text. Public MLS messages, unsupported proposals and incomplete or trailing wire data are rejected. The application sender must match the cryptographically authenticated MLS leaf, preventing a participant from rewrapping another person’s signed text.
Joining changes the MLS epoch. Each active client also refreshes its own leaf approximately every five minutes; a newly admitted client refreshes on its next poll. Old epochs and consumed message generations are not retained. There is no automatic cryptographic rollback. Clients serialize their operations, acquire a short relay write lease before encrypting, and retry only the identical ciphertext. A durable pending packet survives temporary transport errors and retries automatically before another write; state-integrity failures still stop the session. A small pinned-version adapter explicitly strips historical epoch state and preserves the authenticated sender; it does not rely on the library’s zero-retention default, which was found insufficient during review. Write-lease conflicts are retried with bounded backoff and jitter before any encryption, with a 25-second contention budget. Background updates yield to an active writer instead of reporting an ordinary lease conflict as a connection failure. Ending the session cancels waiting before message keys are used. Before sending any ciphertext, the client durably checkpoints the exact packet and its candidate MLS state. After reload, an accepted write is acknowledged through an identical-ciphertext retry; an unpublished packet can use a new lease only at the same relay sequence. Conflicting or missing state fails closed. Welcome is checkpointed before its relay acknowledgement. Checkpoint replacement uses strict IndexedDB transactions and a revision check; storage failure prevents publication.
The creator chooses one name and receives one invitation. A key is bound to one conversation. Everyone shares the deadline, at most 24 hours after creation; joins and key updates cannot extend it. The relay cleans expired rooms, ciphertext, grants, challenges and bindings every second and on requests. It has no chat database, disk archive or backup. Restarting it clears active chats sooner. The relay keeps at most 256 events or 1,000,000 encoded characters per conversation; clients retain at most 256 readable messages, including their encrypted local checkpoint. When the 16-conversation limit is reached, allocation reclaims rooms with no surviving admitted session before rejecting a new chat. Temporary offline status never triggers reclamation. Revoked transport-key bindings remain reserved until their original deadline.
Nicknames, the chat name, MLS KeyPackages and roster bundles are encrypted before reaching the relay. The relay sees temporary transport identifiers, the routing group, membership operations, packet sizes and timing. Short application messages are padded to a 1,024-byte MLS content target; larger messages still reveal size differences. There are no chat cookies, localStorage, analytics, private-key uploads or attachments.
The relay runs separately with no site files, secrets, persistent volume, published port or ordinary Internet egress. Its root filesystem is read-only; it runs as a non-root user with all Linux capabilities dropped, no-new-privileges, 192 MiB memory, one CPU and 32 processes. The gateway uses a fixed internal destination and strips client-IP headers and cookies. Bounds include 16 conversations, 16 admitted transport identities per conversation, 256 sessions, 512 key bindings, 64 challenges, eight pending joins per conversation, four parallel signature verifications and 16 MB of retained event strings globally.
Tor Browser can open the dedicated v3 onion service. It uses the same server and the Tor network; no second rented relay or exit node is needed. A separate restricted Tor service forwards only to a loopback chat gateway. The onion route exposes the chat, security page and required static assets, not the site’s other APIs. The Tor service identity persists so the public address stays stable; it contains no chat history. HTTPS and onion hosts are explicitly allowlisted, with same-origin checks on each.
Replies carry only the original message ID and author fingerprint. The quote is resolved from already verified local history; no quoted plaintext is resent. Reactions are explicit set/remove operations, with one of six supported emoji per participant per message. An interaction-v1 signature binds the operation, target, emoji, text, sender, message ID, epoch, conversation and deadline. The whole envelope is MLS-encrypted; the relay receives no reply or reaction fields. Unknown reaction targets are discarded without a pending queue. Older clients show signed fallback text for reactions and ordinary text for replies.
The browser keeps an AES-256-GCM encrypted checkpoint in IndexedDB until the shared deadline. It includes the temporary identity, current MLS state, relay token and up to 256 locally received messages. The non-extractable wrapping CryptoKey is stored by the same browser; neither it nor the checkpoint is uploaded. Reloading or reopening the same invitation in the same profile and origin restores that participant without signing in again. Web Locks permit only one active MLS writer; other tabs use BroadcastChannel. Closing the page suspends the session without logout. New chat ends the current session, deletes the local record and revokes its transport token. A private browser window, cleared site data, storage eviction or switching origin/device can remove or hide the saved session. The relay must still exist, and its bounded event window must cover the missed updates. Only the owner polls the relay; other tabs receive its verified view without multiplying network requests.
The relay records only the latest successful authenticated poll time for each temporary transport session in RAM. An online flag expires after 20 seconds without a poll; logout removes the session immediately when delivered. No IP address, nickname or permanent last-seen history is added. The encrypted profile contains a connection-v1 signature binding its MLS signing fingerprint to its transport session ID, scoped to this conversation and deadline. Clients reject invalid signatures and duplicate bindings before admission. The UI maps relay connection flags to verified profiles, shows pending admission separately and retains disconnected members in the MLS roster. Relay-reported presence is advisory: a malicious relay can lie about status, and a sleeping browser can delay updates. It does not revoke keys or prove a human is present.
THREAT MODEL
| Actor | Can access | Boundary |
|---|---|---|
| Participant | Own live keys, readable messages, verified profiles and the invitation | Can copy anything they receive. A key is a temporary identity. |
| Another tab in the same browser | Readable UI state and commands through a local BroadcastChannel | One active writer; encrypted local state permits recovery after the owner closes. |
| Ciphertext relay | Routing group, transport keys and grants, encrypted packets, membership operations, size and timing | No invitation secret, MLS private keys, readable names or message text in the protocol. |
| HTTPS edge / hosting network | Peer network address and traffic characteristics | Access logs are disabled. The HTTPS endpoint processes the connection address while connected. |
| Delivered website / device | Browser code, plaintext and live cryptographic state | A trusted part of the protocol: client code and the device can access plaintext and keys. |
| Invitation holder | The ability to request admission before expiry | Cannot recover earlier message keys from the link alone. |
ARCHITECTURE NOTES
Consumed generations and old epochs are discarded. A copied participant state is not healed merely because another member updates. Recovery requires that the affected participant makes an honest update after the attacker loses access to its device. This suite is classical, not post-quantum.
A compromised website, extension, browser or device can steal plaintext and live keys. MLS does not fix hostile JavaScript delivered by the operator. A malicious relay can delay, suppress or partition traffic; transcript comparison helps participants notice divergent views but is not an external transparency service. Compare full key fingerprints and conversation codes through another trusted channel.
Anyone with the full link can join while a participant is online and capacity remains. There is no revocation, moderation or recovery backdoor. Closing a tab does not revoke a copied invitation. If every participant loses their keys, the existing conversation cannot be reconstructed by the server. After losing the original tab’s keys, a returning user creates a new temporary identity.
Expiry removes active application references and best-effort wipes mutable key buffers. JavaScript and browser memory do not guarantee physical zeroization. Recipients can keep messages or screenshots. A malicious host can record ciphertext or metadata. The server cannot recover lost keys, and code cannot erase copies held elsewhere. Local recovery trades memory-only deletion for persistence on this device. The wrapping key prevents raw-key export through Web Crypto, but it is not a password or protection against malicious same-origin code, an unlocked browser profile or a compromised device. Current checkpoints exclude historical MLS epochs; storage snapshots, browser/OS backups and forensic remnants can still retain earlier checkpoints or readable history after local decryption. An open client deletes its record at expiry; while the browser is closed it cannot execute deletion, so expired records are refused and removed on the next visit. Physical erasure is not promised.
Ordinary HTTPS exposes a peer address to the network endpoint even when access logs are disabled. A VPN replaces that address with the provider’s exit address. Tor Browser can separate your access network from the destination; timing correlation, an exposed invitation and a compromised endpoint remain risks. Transport identifiers and traffic patterns remain visible to the relay.
Global and per-session quotas reduce overload without storing IP addresses; fresh keys can still be used for Sybil attacks. A malicious invited participant can disrupt a conversation. Guests need an existing participant online within the two-minute admission window. A tab that misses more than the retained event window must rejoin with a fresh key. Encryption does not guarantee delivery or protection from denial of service.
TESTS AND REPORTS
Tests exercise the actual client and relay: onboarding, up to 16 participants, signatures, tampering, retries, races, one-time challenges, bounds and cleanup, encrypted replies and reactions, reload recovery, interrupted-write recovery, local-record tampering and multiple browser views. Separate laboratory fixtures exercise MLS after state capture and key updates. Expiry checks use an injected test clock.
Interface and multiple tabs ↗ · Delivery and session recovery ↗ · Findings and remediation ↗ · Results and full test list ↗ · Browser, HTTP and Tor ↗ · JSON / SHA-256 ↗
Each report records its date, runtime, raw TAP results, scope and source SHA-256 hashes. Run the scenarios against the published code.
npm ci npm run test:chat:report npm run lint npm run build