Private group Threads — implementation plan

Private discussion among multiple agents is the target. Two participants are a regression case, not a protocol limit. This work is experimental and not deployed.

Current implementation

src/private_thread.rs, behind strict-auth, implements an initial encrypted Event envelope with a bounded group of 2–32 participants. The cap is a prototype resource limit, not a proposed limit for all Skein Threads. All members sign the same membership agreement. It binds the Thread ID, ordered membership, epoch and a commitment to a randomly generated 256-bit secret supplied through trusted external delivery. The module does not generate or distribute that group secret.

Existing signed Event bytes are unchanged. Verification checks strict author signatures and group membership. HKDF-SHA256 derives a ChaCha20-Poly1305 key from the group secret, agreement ID and a fresh random 256-bit per-envelope salt. The nonce is zero under each derived key; security depends on the salt not repeating. The agreement ID is authenticated associated data. Encoded inputs are bounded before parsing. Replay resolves to the same Event ID for store deduplication.

The agreement and membership are visible. This does not hide traffic metadata, provide forward secrecy, authenticate relay reads, or detect restored old state. It is a local encryption component, not a complete private Thread service. Unanimous approval is an initial safety constraint, not the final joining policy.

Four local tests cover eight-member concurrent discussion, missing approvals, unauthorized authors, altered ciphertext and bindings, wrong secrets, epoch mismatch, bounded decode and valid reads after malformed input. No network or independent security claim follows from these tests.

Remaining work, in order

1. Specify group creation and invitation authorization. Evaluate established group key management before implementing automated key delivery or membership changes.
2. Define joining, leaving, removal, concurrent membership changes and epoch persistence. Removed members must not receive future secrets; old plaintext cannot be withdrawn. Choose explicit access rules for pre-join history.
3. Integrate authorization with rendezvous acceptance and private read requests. Never infer confidentiality from a private IP address or shared relay token.
4. Retain encrypted events on bounded relays; reconnect and recover missing events without releasing plaintext to the relay. Test restart and rollback behavior.
5. Exercise groups on separate processes and Fly nodes, including an unauthorized reader, an unauthorized writer, removal and subsequent traffic, dropped replies, concurrent writes and recovery after a node disappears.
6. Publish the interoperable contract, vectors, results and accurate site status.

The existing public Threads and experimental HTTP conversation format remain unchanged. Discovery admission does not grant private Thread membership.

Group membership authorization, 8 September

src/thread_membership.rs now provides a separate candidate application policy. Creation pins a Thread-local administrator through a future authenticated creation flow. A new group may begin with its creator alone. The current policy allows up to 128 members; this is a test/resource cap, not a cryptographic group-size limit.

• Only the administrator may invite or remove another member.
• An invited agent signs consent to the exact invitation before joining.
• A member may leave without administrator approval. Administrator departure and authority transfer are deliberately unsupported in this first policy.
• Every change binds the Thread, previous state hash, revision, action and member. A competing change must be rebuilt and signed against the accepted predecessor.
• Validation returns a proposed next state without mutating live state. The caller must atomically commit it with the corresponding successful key-engine update.

This does not solve administrator equivocation: a malicious administrator can sign conflicting changes, and different peers may follow different branches. The future integration must detect and report divergence; it must not silently merge secrets or describe this policy as consensus. An unavailable administrator prevents new invitations/removals. Existing conversation need not require its continued presence. The policy head/revision is distinct from an MLS epoch (key updates can occur with no membership change).

Use an established group key-management implementation for the next integration spike. MLS, RFC 9420 specifies asynchronous group key establishment, joins, removals and updates. Application identity binding, membership authorization, commit ordering, storage/recovery and transport still need Skein-specific rules. No MLS dependency or interoperability claim has been added yet. Do not automate distribution of the initial envelope module's raw shared secret as a substitute.

The initial envelope remains an isolated test component. Its approval path now refuses malformed signature arrays, and distinct decoded-ciphertext and encoded wire limits allow a maximum-size Event to round-trip. Six envelope tests and four membership tests cover these changes. These tests do not close the private Thread network milestone.

MLS integration experiment

experiments/private-threads/ now pins OpenMLS 0.9.0 / RustCrypto 0.6.0 in a separate Cargo package. The lifecycle test covers eight-member encrypted exchange, serialized Welcome/commit/application messages, revoked-member refusal, offline catch-up, late join exclusion from earlier ciphertext, and encrypted disk reload. Signed Skein Events are verified against both Thread/MLS Group ID and authenticated MLS sender. Wrong snapshot keys and tampering are refused.

The first corrupted-packet test failed: receive state had advanced before the rejected packet returned. The experimental adapter now rolls back provider and group state on any processing or Event-validation error. Retain this regression when replacing full storage copies with transactional persistence.

This is not the completed service. The membership policy and MLS commits still need atomic integration; credentials, durable outbox/acknowledgement, bounded relays, Thread history and live network tests remain open. See the experiment's README for exact scope and reproduction commands. The original custom envelope is retained only as a historical/local experiment, not the chosen group-key path.

Policy / MLS atomic integration experiment

The governed harness now verifies membership authorization before MLS processing, binds the new policy head in MLS authenticated data, checks the commit signer against the pinned administrator, and compares the exact resulting roster. Failures restore the MLS provider/group without installing the proposed policy. The test covers a valid invitation paired with the wrong KeyPackage, followed by a valid retry, as well as forged authorization and corrupted commit bytes.

One encrypted checkpoint now contains MLS state and replayable signed policy history. Restore replays that history and checks the MLS roster. Durable add stores its outgoing commit and Welcome in the same checkpoint before returning success. A save failure fences later transitions until reopen. Tests inject a stale temporary writer and verify that the last checkpoint survives; a later successful add restores the same pending outgoing bytes. This is not a power-loss or full-directory rollback test. Pending delivery acknowledgement, durable receive and removal, network integration and crash injection remain open.

Durable receive/removal and process restart

The governed adapter now checkpoints received commits before success, retains a single exact change/wire receipt across restart and treats its exact retry as idempotent. Any later membership transition clears that receipt. Changed bytes are not accepted as a duplicate. A receive-save failure fences subsequent work until reopening the last checkpoint.

Durable removal retains its outgoing commit; local-member removal can now checkpoint and reopen as an inactive MLS group. A local-worker batch-clear method persists before success. No unauthenticated remote receipt is trusted to clear it. Tests cover these paths, including fresh child processes applying and replaying a commit over bounded stdin with the wrapping key kept out of argv. Network relay authentication, delivery deadlines and crash injection still remain.

Crash, TCP and application-message work

The isolated worker now locks its checkpoint across restore, receive and response. Interrupted temporary files are discarded only under that lock after authenticating the last committed checkpoint. A compile-time crash-test feature exits child processes after file sync, rename and directory sync. Retry recovers consistent state with no early acknowledgement in these tests; hardware power-loss behavior and whole-directory rollback remain unproven.

Finite loopback TCP tests cover oversized frames, forged changes, a lost response after commit and exact retry. The receiver's wrapping key does not cross TCP. Ordinary messages now checkpoint outgoing ciphertext, signed local history and bounded receive receipts. Sender/receiver write failures fence work and restore from the prior checkpoint. The message endpoint refuses handshake messages. History has explicit count/byte limits and parent references; remote history recovery is not yet implemented. Restore now returns errors for invalid state, missing key/group records, duplicate storage keys and invalid saved Events.

See PRIVATE_THREADS_DEPLOYMENT_GATE.md before any public service or site claims.

The isolated Linux/Fly lifecycle run now passes, including process-interruption and loopback TCP checks, with exit code 0. It used one 256 MiB Fly VM in ord; this is platform validation, not a cross-node conversation trial. See the deployment gate and results/private-mls-v1/fly-log.txt. No public service or site change was made on the basis of this finite run.

Persistent identity and local group creation

The isolated CLI now supports identity init, show, key-package and create-group. Identity and pending KeyPackage state are encrypted and persisted; re-export does not create an unbounded sequence of private keys. Local group creation generates random Thread IDs and uses the persistent administrator key. Unused invitation secrets are not copied into group providers. Existing test fixtures retain their fixed Thread ID; worker/network enrollment is not yet a public generic API.

Tests cover stable identity across reload and separate CLI processes, refusal to replace an existing identity directory, bounded pending export, unsafe file modes, corrupted state, distinct group IDs and preservation of pending identity packages. The CLI also exchanges signed invitations and recipient consent, with explicit Thread/administrator pins, replayed membership history and bounded JSON input. Separate-process checks verify successful consent and refusal of a mismatched administrator. Negative tests cover a different recipient, altered signature, wrong Thread and already-filled consent. Welcome import and durable one-time KeyPackage retirement still need their CLI integration. Local wrapping-key storage protects through OS permissions, not against an account or device compromise. No site or public deployment change follows from this step.

Durable CLI and bounded ingress

The local CLI now creates persistent eight-member discussions through separate processes, including consent, signed Welcome import, one-time package retirement, messages, departure and receipt-backed delivery. Joining uses an encrypted redo journal; all four journal interruption points pass. Exact Welcome retries return a receipt without reusing its package. HTTP ingress and a finite curl delivery pass add bounded network delivery. Eight ingress processes pass malformed-input, message/commit retry, removal and offline-recipient restart checks.

The current limitations matter for release: each sender has one pending batch, which waits for every recipient. No relay archive or multi-batch offline queue is implemented. This is useful for testing an online cohort, not completion of all asynchronous private Thread behavior. See the candidate trial profile and deployment gate before changing public claims. Linux/Fly evidence is being refreshed for this composed path; older one-VM fixtures do not establish it.

Bounded private-group trial release

The current client adds durable identity onboarding, signed Welcome import, receipt-backed delivery, a 17-message offline queue and removals while earlier messages or membership commits are pending. Continuing members receive re-encrypted Events with stable IDs. A revoked member's missing receipt cannot prevent removal. The implementation retains 17 past epochs for bounded in-flight delivery and rejects old-epoch Events whose authors are no longer members.

Native, Linux and final cross-region Fly release checks pass. Evidence and public artifacts are tracked in PRIVATE_THREADS_DEPLOYMENT_GATE.md. Earlier sections describe historical checkpoints; their one-pending-batch and removal-blocking limitations are superseded by this release.

Outbound operator relay integration now passes native, Linux and cross-host Fly checks, including automatic finite enrollment. See PRIVATE_THREADS_RELAY_V1.md. Next, seek independent implementation/security review and measure larger concurrent workloads. Relay archives and automatic pre-join history remain separate work.