quicproquo/docs/src/roadmap/milestones.md

# Milestone Tracker

This page tracks the project milestones for quicproquo, from initial transport
layer through post-quantum cryptography. Each milestone produces production-ready,
tested, deployable code -- see [Coding Standards](../contributing/coding-standards.md)
for what that means in practice.

---

## Milestone Summary

| # | Name | Status | What it adds |
|---|------|--------|-------------|
| M1 | QUIC/TLS Transport | **Complete** | QUIC + TLS 1.3 endpoint, length-prefixed framing, Ping/Pong |
| M2 | Authentication Service | **Complete** | Ed25519 identity, KeyPackage generation, AS upload/fetch |
| M3 | Delivery Service + MLS Groups | **Complete** | DS relay, GroupMember create/join/add/send/recv |
| M4 | Group CLI Subcommands | **Complete** | Persistent CLI (create-group, invite, join, send, recv), OPAQUE login |
| M5 | Multi-party Groups | **Complete** | N > 2 members, Commit fan-out, send --all, epoch sync |
| M6 | Persistence | **Complete** | SQLite/SQLCipher, migrations, durable server + client state |
| M7 | Post-quantum | **Next** | PQ hybrid for MLS/HPKE (X25519 + ML-KEM-768) |

---

## M1 -- QUIC/TLS Transport (Complete)

**Goal:** Two processes establish a QUIC connection over TLS 1.3 and exchange
typed Cap'n Proto frames.

**Deliverables:**

- `schemas/envelope.capnp`: `Envelope` struct with `MsgType` enum (Ping/Pong at this stage)
- `quicproquo-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
  canonical serialisation helpers
- `quicproquo-core`: Ed25519 identity keypair generation,
  Cap'n Proto frame codec (Tokio `Encoder`/`Decoder`)
- `quicproquo-server`: QUIC listener with TLS 1.3 (quinn/rustls), Ping to Pong
  handler, one tokio task per connection
- `quicproquo-client`: connects over QUIC, sends Ping, receives Pong, exits 0
- Integration test: server and client in same test binary using `tokio::spawn`
- `docker-compose.yml` running the server

**Tests:** codec (7 unit tests), keypair (3 unit tests), QUIC transport integration.

**Branch:** `feat/m1-noise-transport`

---

## M2 -- Authentication Service (Complete)

**Goal:** Clients register an Ed25519 identity and publish/fetch MLS KeyPackages
via Cap'n Proto RPC.

**Deliverables:**

- `schemas/auth.capnp`: `AuthenticationService` interface (`uploadKeyPackage`,
  `fetchKeyPackage`)
- `quicproquo-core`: Ed25519 identity keypair generation, MLS KeyPackage
  generation via `openmls`
- `quicproquo-server`: AS RPC server with `DashMap` store, atomic consume-on-fetch
- `quicproquo-client`: `register-state` and `fetch-key` CLI subcommands
- Integration test: Alice uploads KeyPackage, Bob fetches it, fingerprints match

**Tests:** auth\_service.rs integration tests (upload, fetch, consume semantics).

---

## M3 -- Delivery Service + MLS Groups (Complete)

**Goal:** Alice creates a group and adds Bob via MLS Welcome. Both exchange
encrypted application messages through the Delivery Service.

**Deliverables:**

- Unified `NodeService` on port 7000 combining Authentication Service and Delivery
  Service into a single Cap'n Proto RPC interface
- `GroupMember` struct with full MLS lifecycle: `create_group`, `add_member`,
  `join_from_welcome`, `send_message`, `receive_message`
- DS relay with `enqueue`, `fetch`, and `fetchWait` (long-polling) operations
- `demo-group` subcommand exercising the complete Alice/Bob flow in one process
- Channel-aware delivery: messages routed by `(channelId, recipientKey)`

**Tests:** All passing -- codec (5+ tests), keypair (3 tests), group round-trip,
group\_id lifecycle, MLS integration.

**Key design decisions from M3:**

1. **OpenMlsRustCrypto backend holds the HPKE init key in memory.** The same
   `GroupMember` instance that generated the KeyPackage must process the
   corresponding Welcome. If the process exits in between, the init private key
   is lost. This is by design for M3; persistence comes at M6.

2. **KeyPackage wire format: raw TLS-encoded bytes.** KeyPackages are serialised
   using `tls_serialize_detached()` rather than wrapped in `MlsMessageOut`. This
   avoids an extra layer of indirection and matches what `openmls` expects on the
   receive side via `KeyPackageIn::tls_deserialize_exact()`.

3. **openmls 0.5 API gotchas.** Several `openmls` methods changed signatures
   between 0.4 and 0.5 (e.g., `MlsGroup::new` vs `MlsGroup::new_with_group_id`,
   `BasicCredential::new` taking `Vec<u8>` directly). These differences are
   documented inline in `quicproquo-core/src/group.rs`.

**Branch:** `feat/m1-noise-transport`

---

## M4 -- Group CLI Subcommands (Complete)

**Goal:** Persistent, composable CLI subcommands for group operations, replacing
the monolithic `demo-group` proof-of-concept.

**Deliverables:** `create-group`, `invite`, `join`, `send`, `recv`, `chat`;
OPAQUE `register-user` and `login`; `demo-group` remains for single-command demo.

---

## M5 -- Multi-party Groups (Complete)

**Goal:** Support groups with N > 2 members, including Commit fan-out and
epoch synchronisation.

**Deliverables:** Commit fan-out to existing members on invite; `send --all`;
`cmd_join` processes all queued payloads (Welcome + Commits); three-party E2E
passing. Proposal handling (Remove, Update) and Criterion benchmarks are
optional follow-ups.

---

## M6 -- Persistence (Complete)

**Goal:** Server survives restart. Client state persists across sessions.

**Deliverables:** SQLite/SQLCipher via rusqlite, `migrations/` directory and
migration runner; client state file and DiskKeyStore (encrypted QPCE optional).
See [Future Research: SQLCipher](future-research.md#storage--persistence) for
encrypted-at-rest options.

---

## M7 -- Post-quantum (Next)

**Goal:** Replace the MLS crypto backend with a hybrid X25519 + ML-KEM-768 KEM,
providing post-quantum confidentiality for all group key material.

**Deliverables:**

- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicproquo-core`
- Hybrid shared secret derivation:

  ```
  SharedSecret = HKDF-SHA256(
    ikm  = X25519_ss || ML-KEM-768_ss,
    info = "quicproquo-hybrid-v1",
    len  = 32
  )
  ```

- All M3/M4/M5 tests pass unchanged with the new ciphersuite
- Follows the combiner approach from `draft-ietf-tls-hybrid-design`

The `ml-kem` crate is already vendored in the workspace. See
[Hybrid KEM](../protocol-layers/hybrid-kem.md) for the detailed design.

---

## Cross-references

- [Production Readiness WBS](production-readiness.md) -- phased work breakdown
  for hardening beyond the milestone track
- [Auth, Devices, and Tokens](authz-plan.md) -- authentication and authorisation
  design that cuts across M4--M6
- [1:1 Channel Design](dm-channels.md) -- DM channel schema and authz model
- [Future Research](future-research.md) -- technology options for M6+ and beyond
- [Testing Strategy](../contributing/testing.md) -- how tests are structured
  across milestones