chore: rename project quicnprotochat -> quicproquo (binaries: qpq)

Rename the entire workspace:
- Crate packages: quicnprotochat-{core,proto,server,client,gui,p2p,mobile} -> quicproquo-*
- Binary names: quicnprotochat -> qpq, quicnprotochat-server -> qpq-server,
  quicnprotochat-gui -> qpq-gui
- Default files: *-state.bin -> qpq-state.bin, *-server.toml -> qpq-server.toml,
  *.db -> qpq.db
- Environment variable prefix: QUICNPROTOCHAT_* -> QPQ_*
- App identifier: chat.quicnproto.gui -> chat.quicproquo.gui
- Proto package: quicnprotochat.bench -> quicproquo.bench
- All documentation, Docker, CI, and script references updated

HKDF domain-separation strings and P2P ALPN remain unchanged for
backward compatibility with existing encrypted state and wire protocol.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/src/roadmap/authz-plan.md

@@ -1,7 +1,7 @@
 # Auth, Devices, and Tokens
 
 This page describes the authentication, device management, and authorisation
-design for quicnprotochat. It introduces account and device identities, gates
+design for quicproquo. It introduces account and device identities, gates
 server operations by authenticated identity, enforces rate and size limits, and
 binds MLS identity keys to accounts.
 

docs/src/roadmap/dm-channels.md

@@ -1,7 +1,7 @@
 # 1:1 Channel Design
 
 This page describes the design for first-class 1:1 (direct message) channels in
-quicnprotochat. Channels provide per-conversation authorisation, MLS-encrypted
+quicproquo. Channels provide per-conversation authorisation, MLS-encrypted
 payloads, message retention with TTL eviction, and backward compatibility with
 the legacy delivery model.
 

docs/src/roadmap/fully-operational-checklist.md

@@ -109,7 +109,7 @@ Not strictly required for “operational” but expected for production deployme
 ## 3. Roadmap and Documentation Updates
 
 - **Milestones doc:** Mark M4 as **Complete** (CLI subcommands exist). Mark M6 as **Complete** (migrations + runner; server and client persistence in place). Leave M5 as **Next** and M7 as **Planned**.
-- **README:** Update milestone table to reflect M4 and M6 complete; add one line on migrations (e.g. “Server supports SQL migrations under `quicnprotochat-server/migrations/`”).
+- **README:** Update milestone table to reflect M4 and M6 complete; add one line on migrations (e.g. “Server supports SQL migrations under `quicproquo-server/migrations/`”).
 - **Migration convention:** Document in README or a dev doc: add new migrations as `NNN_name.sql`, add to `MIGRATIONS` in `sql_store.rs`, bump `SCHEMA_VERSION`.
 
 ---

docs/src/roadmap/future-research.md

@@ -1,7 +1,7 @@
 # Future Research Directions
 
 This page catalogues technologies and research directions that could strengthen
-quicnprotochat beyond the current [milestone plan](milestones.md). Each entry
+quicproquo beyond the current [milestone plan](milestones.md). Each entry
 includes a brief description, the problem it solves, relevant crates or
 specifications, and how it maps to the project architecture.
 
@@ -21,7 +21,7 @@ delivery.
 **Solution:** [LibP2P](https://libp2p.io/) and [iroh](https://iroh.computer/)
 (from n0) provide peer discovery, NAT traversal (hole-punching), and relay
 fallback. iroh is particularly interesting because it is Rust-native and built on
-QUIC, aligning with quicnprotochat's existing transport layer.
+QUIC, aligning with quicproquo's existing transport layer.
 
 **Architecture impact:** Move from pure client-server to a hybrid topology where
 peers communicate directly when possible and fall back to server relay when NAT
@@ -68,7 +68,7 @@ significantly, so this should be optional.
 
 ### SQLCipher / libsql (Turso)
 
-**Problem:** At M6, quicnprotochat needs persistent storage for group state, key
+**Problem:** At M6, quicproquo needs persistent storage for group state, key
 material, and message queues. Storing private keys in a plaintext SQLite database
 is insufficient.
 
@@ -129,7 +129,7 @@ vulnerable to harvest-now-decrypt-later attacks.
 hybrid Ed25519 + ML-DSA-65 for credential signatures. The `ml-kem` crate is
 already vendored in the workspace.
 
-**Architecture impact:** Custom `OpenMlsCryptoProvider` in `quicnprotochat-core`
+**Architecture impact:** Custom `OpenMlsCryptoProvider` in `quicproquo-core`
 implementing the hybrid combiner. This is the M7 milestone -- see
 [Milestones](milestones.md#m7----post-quantum-planned) and
 [Hybrid KEM](../protocol-layers/hybrid-kem.md).
@@ -202,7 +202,7 @@ DID URIs. The server resolves DIDs to public keys for routing.
 
 ### OPAQUE (aPAKE)
 
-**Problem:** If quicnprotochat adds password-based account registration, the
+**Problem:** If quicproquo adds password-based account registration, the
 server must never see the password -- not even a hash.
 
 **Solution:** [OPAQUE](https://datatracker.ietf.org/doc/rfc9497/) is an
@@ -253,7 +253,7 @@ admin could require proof of organization membership before allowing join.
 **Problem:** A single server is a single point of failure and a single point of
 trust. Users on different servers cannot communicate.
 
-**Solution:** Federation allows multiple quicnprotochat servers to exchange
+**Solution:** Federation allows multiple quicproquo servers to exchange
 messages, similar to [Matrix](https://matrix.org/) homeserver federation. Each
 server manages its own users and relays messages to peer servers.
 
@@ -345,10 +345,10 @@ the user base for testing and demonstration.
 
 **Solution:** [Tauri](https://tauri.app/) or [Dioxus](https://dioxuslabs.com/)
 provide native cross-platform GUI frameworks in Rust. The
-`quicnprotochat-core` crate can be shared directly with the GUI client.
+`quicproquo-core` crate can be shared directly with the GUI client.
 
-**Architecture impact:** Add a `quicnprotochat-gui` crate that depends on
-`quicnprotochat-core` and `quicnprotochat-proto`. The GUI drives the same
+**Architecture impact:** Add a `quicproquo-gui` crate that depends on
+`quicproquo-core` and `quicproquo-proto`. The GUI drives the same
 `GroupMember` and RPC logic as the CLI client.
 
 **Crates:** `tauri`, `dioxus`
@@ -361,7 +361,7 @@ provide native cross-platform GUI frameworks in Rust. The
 [diplomat](https://github.com/nickelc/diplomat) generate idiomatic Swift and
 Kotlin bindings from Rust definitions.
 
-**Architecture impact:** Expose `quicnprotochat-core` through a C-compatible FFI
+**Architecture impact:** Expose `quicproquo-core` through a C-compatible FFI
 layer. Mobile apps call into the Rust crypto and protocol logic.
 
 **Crates:** `uniffi`, `diplomat`
@@ -387,10 +387,10 @@ considering the current state of the codebase and the [milestone plan](milestone
 
 | Priority | Technology | Why | Unlocks |
 |----------|-----------|-----|---------|
-| 1 | **Post-quantum hybrid KEM** | `ml-kem` is already vendored in the workspace. Completing the hybrid `OpenMlsCryptoProvider` makes quicnprotochat one of the first PQ MLS implementations. | M7 |
+| 1 | **Post-quantum hybrid KEM** | `ml-kem` is already vendored in the workspace. Completing the hybrid `OpenMlsCryptoProvider` makes quicproquo one of the first PQ MLS implementations. | M7 |
 | 2 | **SQLCipher persistence** | Encrypted-at-rest storage is the prerequisite for multi-device support, offline usage, and server restart survival. | M6 |
 | 3 | **OPAQUE auth** | Zero-knowledge password authentication is a massive security uplift for the account system. The server never sees or stores passwords. | Phase 3 (authz) |
-| 4 | **iroh / LibP2P** | NAT traversal and optional P2P mesh makes quicnprotochat deployable without centralised infrastructure. Aligns with the existing QUIC transport. | Beyond M7 |
+| 4 | **iroh / LibP2P** | NAT traversal and optional P2P mesh makes quicproquo deployable without centralised infrastructure. Aligns with the existing QUIC transport. | Beyond M7 |
 | 5 | **Sealed Sender + PIR** | Content encryption is table stakes. Metadata resistance (hiding who talks to whom) is the frontier of private messaging research. | Beyond M7 |
 
 ---

docs/src/roadmap/milestones.md

@@ -1,6 +1,6 @@
 # Milestone Tracker
 
-This page tracks the project milestones for quicnprotochat, from initial transport
+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.
@@ -29,13 +29,13 @@ typed Cap'n Proto frames.
 **Deliverables:**
 
 - `schemas/envelope.capnp`: `Envelope` struct with `MsgType` enum (Ping/Pong at this stage)
-- `quicnprotochat-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
+- `quicproquo-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
   canonical serialisation helpers
-- `quicnprotochat-core`: Ed25519 identity keypair generation,
+- `quicproquo-core`: Ed25519 identity keypair generation,
   Cap'n Proto frame codec (Tokio `Encoder`/`Decoder`)
-- `quicnprotochat-server`: QUIC listener with TLS 1.3 (quinn/rustls), Ping to Pong
+- `quicproquo-server`: QUIC listener with TLS 1.3 (quinn/rustls), Ping to Pong
   handler, one tokio task per connection
-- `quicnprotochat-client`: connects over QUIC, sends Ping, receives Pong, exits 0
+- `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
 
@@ -54,10 +54,10 @@ via Cap'n Proto RPC.
 
 - `schemas/auth.capnp`: `AuthenticationService` interface (`uploadKeyPackage`,
   `fetchKeyPackage`)
-- `quicnprotochat-core`: Ed25519 identity keypair generation, MLS KeyPackage
+- `quicproquo-core`: Ed25519 identity keypair generation, MLS KeyPackage
   generation via `openmls`
-- `quicnprotochat-server`: AS RPC server with `DashMap` store, atomic consume-on-fetch
-- `quicnprotochat-client`: `register-state` and `fetch-key` CLI subcommands
+- `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).
@@ -97,7 +97,7 @@ group\_id lifecycle, MLS integration.
 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 `quicnprotochat-core/src/group.rs`.
+   documented inline in `quicproquo-core/src/group.rs`.
 
 **Branch:** `feat/m1-noise-transport`
 
@@ -143,13 +143,13 @@ providing post-quantum confidentiality for all group key material.
 
 **Deliverables:**
 
-- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicnprotochat-core`
+- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicproquo-core`
 - Hybrid shared secret derivation:
 
   ```
   SharedSecret = HKDF-SHA256(
     ikm  = X25519_ss || ML-KEM-768_ss,
-    info = "quicnprotochat-hybrid-v1",
+    info = "quicproquo-hybrid-v1",
     len  = 32
   )
   ```

docs/src/roadmap/phase2-and-m4-m6.md

@@ -21,7 +21,7 @@ The following legacy behaviour has been removed; only current behaviour is suppo
 
 | Task | Status | Notes |
 |------|--------|-------|
-| **Ciphersuite allowlist** | **Done** | Server rejects KeyPackages whose ciphersuite is not `MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519`. See `quicnprotochat_core::validate_keypackage_ciphersuite` and `upload_key_package` (E021). |
+| **Ciphersuite allowlist** | **Done** | Server rejects KeyPackages whose ciphersuite is not `MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519`. See `quicproquo_core::validate_keypackage_ciphersuite` and `upload_key_package` (E021). |
 | **ALPN enforcement** | **Done** | Server TLS config sets `alpn_protocols = [b"capnp"]`; handshake completes only if client offers `capnp`. |
 | **Connection draining** | **Done** | On `Ctrl+C`, server calls `endpoint.close(0, b"server shutdown")` and exits the accept loop. |
 | **Wire versioning** | **Done** | `enqueue`, `fetch`, `fetchWait` require `version == CURRENT_WIRE_VERSION` (1). Other RPCs use auth version. |

docs/src/roadmap/production-readiness.md

@@ -1,6 +1,6 @@
 # Production Readiness WBS
 
-This page defines the work breakdown structure (WBS) for taking quicnprotochat
+This page defines the work breakdown structure (WBS) for taking quicproquo
 from a proof-of-concept to a production-hardened system. It covers feature scope,
 security policy, phased delivery, and a planning checklist.
 
@@ -11,7 +11,7 @@ document focuses on the cross-cutting concerns that span multiple milestones.
 
 ## Feature Scope (Must-Have)
 
-These are the feature areas that must be addressed before quicnprotochat can be
+These are the feature areas that must be addressed before quicproquo can be
 considered production-ready. Each area maps to one or more milestones or phases
 in the WBS below.
 
@@ -30,7 +30,7 @@ in the WBS below.
 
 ## Security Plan (By Design)
 
-quicnprotochat follows a security-by-design philosophy. The standards below are
+quicproquo follows a security-by-design philosophy. The standards below are
 non-negotiable -- see [Coding Standards](../contributing/coding-standards.md) for
 how they are enforced in code.