chore: rename quicproquo → quicprochat in docs, Docker, CI, and packaging
Rename all project references from quicproquo/qpq to quicprochat/qpc across documentation, Docker configuration, CI workflows, packaging scripts, operational configs, and build tooling. - Docker: crate paths, binary names, user/group, data dirs, env vars - CI: workflow crate references, binary names, artifact names - Docs: all markdown files under docs/, SDK READMEs, book.toml - Packaging: OpenWrt Makefile, init script, UCI config (file renames) - Scripts: justfile, dev-shell, screenshot, cross-compile, ai_team - Operations: Prometheus config, alert rules, Grafana dashboard - Config: .env.example (QPQ_* → QPC_*), CODEOWNERS paths - Top-level: README, CONTRIBUTING, ROADMAP, CLAUDE.md
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
# Auth, Devices, and Tokens
|
||||
|
||||
This page describes the authentication, device management, and authorisation
|
||||
design for quicproquo. It introduces account and device identities, gates
|
||||
design for quicprochat. It introduces account and device identities, gates
|
||||
server operations by authenticated identity, enforces rate and size limits, and
|
||||
binds MLS identity keys to accounts.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# 1:1 Channel Design
|
||||
|
||||
This page describes the design for first-class 1:1 (direct message) channels in
|
||||
quicproquo. Channels provide per-conversation authorisation, MLS-encrypted
|
||||
quicprochat. Channels provide per-conversation authorisation, MLS-encrypted
|
||||
payloads, message retention with TTL eviction, and backward compatibility with
|
||||
the legacy delivery model.
|
||||
|
||||
|
||||
@@ -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 `quicproquo-server/migrations/`”).
|
||||
- **README:** Update milestone table to reflect M4 and M6 complete; add one line on migrations (e.g. “Server supports SQL migrations under `quicprochat-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`.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Future Research Directions
|
||||
|
||||
This page catalogues technologies and research directions that could strengthen
|
||||
quicproquo beyond the current [milestone plan](milestones.md). Each entry
|
||||
quicprochat 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.
|
||||
|
||||
@@ -94,7 +94,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 `quicproquo-core`
|
||||
**Architecture impact:** Custom `OpenMlsCryptoProvider` in `quicprochat-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).
|
||||
@@ -186,7 +186,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 quicproquo servers to exchange
|
||||
**Solution:** Federation allows multiple quicprochat servers to exchange
|
||||
messages, similar to [Matrix](https://matrix.org/) homeserver federation. Each
|
||||
server manages its own users and relays messages to peer servers.
|
||||
|
||||
@@ -278,10 +278,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
|
||||
`quicproquo-core` crate can be shared directly with the GUI client.
|
||||
`quicprochat-core` crate can be shared directly with the GUI client.
|
||||
|
||||
**Architecture impact:** Add a `quicproquo-gui` crate that depends on
|
||||
`quicproquo-core` and `quicproquo-proto`. The GUI drives the same
|
||||
**Architecture impact:** Add a `quicprochat-gui` crate that depends on
|
||||
`quicprochat-core` and `quicprochat-proto`. The GUI drives the same
|
||||
`GroupMember` and RPC logic as the CLI client.
|
||||
|
||||
**Crates:** `tauri`, `dioxus`
|
||||
@@ -294,7 +294,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 `quicproquo-core` through a C-compatible FFI
|
||||
**Architecture impact:** Expose `quicprochat-core` through a C-compatible FFI
|
||||
layer. Mobile apps call into the Rust crypto and protocol logic.
|
||||
|
||||
**Crates:** `uniffi`, `diplomat`
|
||||
@@ -325,7 +325,7 @@ Items marked **Implemented** are already part of the v2 codebase.
|
||||
| -- | **Post-quantum hybrid KEM** | `ml-kem` vendored; custom `OpenMlsCryptoProvider` with X25519 + ML-KEM-768. | **Implemented** |
|
||||
| -- | **SQLCipher persistence** | Encrypted-at-rest storage via rusqlite + bundled-sqlcipher + Argon2id key derivation. | **Implemented** |
|
||||
| -- | **OPAQUE auth** | Zero-knowledge password authentication via `opaque-ke`. Server never stores passwords. | **Implemented** |
|
||||
| -- | **iroh P2P** | NAT traversal and optional P2P mesh via the `quicproquo-p2p` crate (feature-flagged). | **Implemented** |
|
||||
| -- | **iroh P2P** | NAT traversal and optional P2P mesh via the `quicprochat-p2p` crate (feature-flagged). | **Implemented** |
|
||||
| -- | **Sealed Sender** | `--sealed-sender` flag encrypts sender identity inside MLS ciphertext. | **Implemented** |
|
||||
| 1 | **PIR (Private Information Retrieval)** | Fetch messages without revealing the recipient's identity to the server. | Future |
|
||||
| 2 | **Key Transparency** | Verifiable, append-only log of public key bindings. Detects key substitution attacks. | Future |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Milestone Tracker
|
||||
|
||||
This page tracks the project milestones for quicproquo, from initial transport
|
||||
This page tracks the project milestones for quicprochat, 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)
|
||||
- `quicproquo-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
|
||||
- `quicprochat-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
|
||||
canonical serialisation helpers
|
||||
- `quicproquo-core`: Ed25519 identity keypair generation,
|
||||
- `quicprochat-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
|
||||
- `quicprochat-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
|
||||
- `quicprochat-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`)
|
||||
- `quicproquo-core`: Ed25519 identity keypair generation, MLS KeyPackage
|
||||
- `quicprochat-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
|
||||
- `quicprochat-server`: AS RPC server with `DashMap` store, atomic consume-on-fetch
|
||||
- `quicprochat-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 `quicproquo-core/src/group.rs`.
|
||||
documented inline in `quicprochat-core/src/group.rs`.
|
||||
|
||||
**Branch:** `feat/m1-noise-transport`
|
||||
|
||||
@@ -142,13 +142,13 @@ providing post-quantum confidentiality for all group key material.
|
||||
|
||||
**Deliverables:**
|
||||
|
||||
- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicproquo-core`
|
||||
- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicprochat-core`
|
||||
- Hybrid shared secret derivation:
|
||||
|
||||
```
|
||||
SharedSecret = HKDF-SHA256(
|
||||
ikm = X25519_ss || ML-KEM-768_ss,
|
||||
info = "quicproquo-hybrid-v1",
|
||||
info = "quicprochat-hybrid-v1",
|
||||
len = 32
|
||||
)
|
||||
```
|
||||
|
||||
@@ -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 `quicproquo_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 `quicprochat_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. |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Production Readiness WBS
|
||||
|
||||
This page defines the work breakdown structure (WBS) for taking quicproquo
|
||||
This page defines the work breakdown structure (WBS) for taking quicprochat
|
||||
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 quicproquo can be
|
||||
These are the feature areas that must be addressed before quicprochat 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)
|
||||
|
||||
quicproquo follows a security-by-design philosophy. The standards below are
|
||||
quicprochat 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.
|
||||
|
||||
@@ -44,7 +44,7 @@ how they are enforced in code.
|
||||
### Transport Policy
|
||||
|
||||
- TLS 1.3 only (`rustls` configured with `TLS13` cipher suites exclusively).
|
||||
- ALPN token `b"qpq"` required; reject connections with mismatched ALPN.
|
||||
- ALPN token `b"qpc"` required; reject connections with mismatched ALPN.
|
||||
- Self-signed certificates acceptable for development; production deployments
|
||||
must use a CA-signed certificate or certificate pinning.
|
||||
- Connection draining on shutdown (QUIC `CONNECTION_CLOSE`).
|
||||
@@ -128,7 +128,7 @@ how they are enforced in code.
|
||||
| Wire versioning | Version field in all Protobuf frames; reject unknown versions |
|
||||
| Ciphersuite allowlist | Server rejects KeyPackages outside the allowed set |
|
||||
| Downgrade guards | Prevent epoch rollback; reject Commits with weaker ciphersuites |
|
||||
| ALPN enforcement | Reject connections without `b"qpq"` ALPN token |
|
||||
| ALPN enforcement | Reject connections without `b"qpc"` ALPN token |
|
||||
| Connection draining | Graceful QUIC `CONNECTION_CLOSE` on server shutdown |
|
||||
| KeyPackage rotation | Client-side timer to upload fresh KeyPackages before TTL expiry |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user