Current project status

Today: a command-line protocol demo, not a chat app.

Phase 1 laboratory work is complete: the headless two-person flow, hostile inputs, deterministic delivery faults, and encrypted SQLCipher authorization recovery passed the Linux, macOS, and Windows gate. Connected Iroh FastV1 delivery is experimental. Product key custody, a human approval screen, desktop packaging, offline delivery, and production network transports remain later work.

What you can run today.

The sessionctl command runs an Alice-and-Bob flow through the composed laboratory components and deterministic local transport.

Create → protect → approve → join → message → update → remove.

sessionctl creates a private capability invitation, protects Bob’s join request, records a simulated approval, delivers the MLS Welcome, exchanges protected messages in both directions, updates the group, removes Bob, and confirms that Bob’s post-removal access is rejected.

The independent-process runner and checked fault suites also retain restart and Welcome-delivery recovery evidence. The Phase 1 evidence matrix records the exact tested revision and the remaining product, physical-durability, and platform-key limits.

Protocol objects: Canonical envelopes, invitation v1/v2, protected join framing, exact AAD, and local deposit endpoint.; bounded fixtures retained
Admission path: HPKE provenance, exact KeyPackage ownership, durable laboratory replay reservation, local invitation binding, and simulated approval.; laboratory composition
MLS path: Two-member Add/Welcome, protected messages, update, removal, replay, and reordering behavior.; isolated adapter
Delivery path: Right-specific local Welcome mailbox, deterministic adverse memory transport, and the authenticated transport-iroh adapter.; experimental online FastV1
Storage evidence: Composed SQLCipher transaction and process-recovery evidence; separate sealed-vault and passphrase-wrapper laboratories.; laboratory only
Platform baseline: Workspace build, lint, and test matrix on Linux, macOS, and Windows CI.; CI gate active

What must happen before people can use it.

This roadmap shows the proposed order of evidence, not delivery dates. Completing one laboratory phase does not prove the whole product is ready.

Phase 1 Protocol prototype: Capability invitation access, two-party MLS, hostile input handling, deterministic delivery faults, and process recovery passed the three-platform laboratory gate.; complete
Validation track Product understanding: Test whether people understand the difference between account proof and trust, verification and approval, device changes, and Fast versus Private network metadata.; before UI selection
Phase 2 Identity independence: Add GitHub control evidence through a minimal bridge while the capability path continues to work unchanged.; planned
Phase 3 Rendezvous + fast delivery: Opaque capability mailboxes, offline delivery, bounded service behavior, a fast direct/relay adapter, and self-hosted realm deployment.; planned
Phase 4 Desktop client: A selected shell around the Rust core, one macOS/Windows/Linux baseline, safe deep links, visible evidence, text chat, and honest retention controls.; planned
Phase 5–6 Privacy + credentials: Private transport experiments and one interoperable credential-admission boundary under the same envelope and KeyPackage contracts.; experimental
Phase 7 Hardening + review: Fuzzing, release provenance, signed updates, dependency review, endpoint and network evidence, operated disclosure, and independent security review.; release gate

How to contribute without overstating progress.

Keep changes small, test failure cases at every untrusted boundary, and make documentation say exactly what the tests prove.

Start with the review package

Read the independent-audit brief and exact claim states.
Inspect the relevant ADR before changing a boundary.
Run the smallest relevant test, then the complete gate.
Add malformed, expired, replayed, reordered, and unauthorized cases where they apply.

Open the repository ↗

Keep the first product small

Two participants.
Capability admission before provider identity.
Text before attachments, voice, or video.
One common desktop baseline before platform-specific claims.
No private-mode fallback that changes the guarantee.