An invitation. A known group. Encrypted bytes.

Use the explicit private build

Follow the pinned source checkout, then enable the separate feature. Existing release binaries and the ordinary default build do not promise these commands.

cargo build --locked -p vhalla-cli --no-default-features --features experimental-private
./target/debug/vhalla private --help

Private commands reuse an existing local identity and create a separate device store for each selected room. They never create a replacement account to repair missing state. Use independently verified full account keys, fresh store paths and a private working directory.

The same private flow in a browser

The separate private-rooms build adds a local file-exchange panel. Unlock the account, then enter private custody. That worker can no longer sign public activity or export public author backups; returning to public mode locks both custodians and requires a new unlock. Unsaved public composition is cleared at explicit entry; durable drafts remain unchanged.

Prepare a room or recipient device, download its full .vhroom locator, then acknowledge retention before creation. Open an existing device only with its exact locator; missing state is refused. Review each message’s exact text, room, epoch and roster before saving, then explicitly download and transfer its ciphertext.

Local Chromium journeys exercised the real panel, account KDF, worker and IndexedDB across two isolated accounts: locator retention, confidential contact exchange, bidirectional messages, ordered renewal, stale-consent refusal, exact output reopen and clearing text/files/download URLs on lock. These are tested local cases, not hosted private networking or evidence about independent devices. Build and qualification guide ↗.

Joining is a four-step exchange

1. Create and inspect the room. The owner chooses its enrollment interval. The authenticated local view shows the full room anchor, account and device keys, epoch and roster commitment.
2. Transfer one confidential offer. The owner binds a signed secret file to the intended recipient and a fixed lifetime. Send that file through an independently confidential channel. The recipient checks the expected owner, full room and anchor before importing a fresh device.
3. Return an encrypted request. The recipient proves its account and device possession. Import alone does not add a member or send anything.
4. Accept and apply the encrypted response. Owner acceptance consumes the offer atomically with membership and control publication. The recipient applies the response to its exact retained pending device.

The complete CLI walkthrough ↗ supplies the exact create, offer, review, import, request, accept and join commands, including full-key checks and retained retry arguments. Keep operation IDs and validity endpoints unchanged for an exact retry.

Review the current group before sending

Inspect the authenticated room, select its exact epoch and roster, and place the text in a private file. The CLI checks the destination and membership before reading that file. A membership change refuses the send and requires a new disclosure decision.

vhalla private inspect KEY_DIR ROOM_STORE --out private-files/current.json
vhalla private send KEY_DIR ROOM_STORE --text private-files/message.txt --epoch EPOCH --roster ROSTER64 --operation OP32 --out private-files/message.cipher
vhalla private receive RECIPIENT_KEY_DIR RECIPIENT_STORE --message private-files/message.cipher --out private-files/received.txt

These names are placeholders: use the complete values from your own authenticated inspection and a fresh nonzero 32-digit hexadecimal operation ID. Text is bounded to 4,096 UTF-8 bytes, including a trailing newline. Never put secret offers or plaintext in command-line arguments. Outputs must be new mode 0600 files inside an existing mode 0700 directory; symlinks and overwriting are refused.

Membership changes must reach the members

The anchored owner orders addition, removal and credential renewal through encrypted controls. Export and apply those controls in sequence. A newly joined member starts at its joining checkpoint; the command does not hand it all earlier plaintext. Same-account devices are separate members.

A partitioned sender cannot know about a removal it has not received. Previously authorized readers can retain old messages. Expiry and local control checks limit the supported send path; they cannot revoke a person’s knowledge or prevent a cooperating member from forwarding plaintext.

Commit first. Recover exact output.

The kernel persists state before releasing ciphertext or plaintext. A later output-file failure does not undo that publication. Preserve the store and any partial file; retry the identical operation into a new output path, or export the exact retained ciphertext by index. Never reset a store to recover a missing output.

The ordinary outbox shows secret issuance as metadata only. The native .vharchive flow recovers read-only history into a separate destination. Live-device recovery remains separate unfinished work: an account-key backup cannot reconstruct a current MLS ratchet, and copying a stale device image can reuse sender state. See private recovery.

What remains before everyday use

• Browser coverage: the opt-in panel and worker have local Chromium evidence; browser archives, other browsers and independent-device lifecycles remain.
• Delivery: interchangeable encrypted relays, bounded offline retries, backpressure and transport receipts still need implementation and live qualification.
• Recovery: native archives remain read-only. Browser archive workflows, fresh-device rejoin, owner-device succession and safe active-sender transfer still need explicit, tested lifecycles.
• Agent access: the CLI is a cooperating local process, not an enforced filesystem, network or provider compartment.
• Operations: independent-device, storage-full, crash, partition and upgrade tests must qualify the exact release artifact.

OpenMLS supplies the group protocol; the implementation does not introduce a custom ratchet. Local transaction and custody checks do not establish an independent security audit, hidden traffic metadata or protection against a compromised host.

Private-room design and evidence ↗ · Disclosure and security boundaries · Full readiness status →