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:
@@ -5,15 +5,15 @@ The Authentication Service handles user registration and login via the OPAQUE as
|
||||
This page covers the server-side OPAQUE flow, session token lifecycle, KeyPackage storage, and hybrid key endpoints.
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicproquo-server/src/domain/` (OPAQUE handlers, session management)
|
||||
- `crates/quicproquo-server/src/sql_store.rs` (SqlStore persistence)
|
||||
- `proto/qpq/v1/auth.proto` (wire schema)
|
||||
- `crates/quicprochat-server/src/domain/` (OPAQUE handlers, session management)
|
||||
- `crates/quicprochat-server/src/sql_store.rs` (SqlStore persistence)
|
||||
- `proto/qpc/v1/auth.proto` (wire schema)
|
||||
|
||||
---
|
||||
|
||||
## OPAQUE Protocol
|
||||
|
||||
quicproquo uses the OPAQUE asymmetric PAKE (RFC 9497) for user authentication. The password never leaves the client and is never known to the server. The server stores an OPAQUE registration record derived from the password, but this record cannot be used to recover the password even if the server is fully compromised.
|
||||
quicprochat uses the OPAQUE asymmetric PAKE (RFC 9497) for user authentication. The password never leaves the client and is never known to the server. The server stores an OPAQUE registration record derived from the password, but this record cannot be used to recover the password even if the server is fully compromised.
|
||||
|
||||
### Registration (IDs 100-101)
|
||||
|
||||
@@ -184,7 +184,7 @@ Returns a range of entries from the append-only log for client-side Merkle verif
|
||||
## Server implementation structure
|
||||
|
||||
```rust
|
||||
// Domain handler (quicproquo-server/src/domain/)
|
||||
// Domain handler (quicprochat-server/src/domain/)
|
||||
struct AuthHandler {
|
||||
store: Arc<SqlStore>, // SQLCipher persistence
|
||||
opaque_server: OpaqueServer, // opaque-ke server state
|
||||
|
||||
@@ -6,8 +6,8 @@ recipient identity key and channel identifier. The DS exposes three operations
|
||||
through the `NodeService` RPC interface: `enqueue`, `fetch`, and `fetchWait`.
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicproquo-server/src/main.rs` (RPC handlers)
|
||||
- `crates/quicproquo-server/src/storage.rs` (queue storage)
|
||||
- `crates/quicprochat-server/src/main.rs` (RPC handlers)
|
||||
- `crates/quicprochat-server/src/storage.rs` (queue storage)
|
||||
- `schemas/node.capnp` (wire schema)
|
||||
|
||||
---
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# GroupMember Lifecycle
|
||||
|
||||
The `GroupMember` struct in `quicproquo-core` is the core MLS state machine
|
||||
The `GroupMember` struct in `quicprochat-core` is the core MLS state machine
|
||||
that manages a single client's membership in an MLS group. It wraps an openmls
|
||||
`MlsGroup`, a persistent crypto backend, and the long-term Ed25519 identity
|
||||
keypair. Every MLS operation -- key package generation, group creation, member
|
||||
addition, joining, sending, and receiving -- flows through this struct.
|
||||
|
||||
**Source:** `crates/quicproquo-core/src/group.rs`
|
||||
**Source:** `crates/quicprochat-core/src/group.rs`
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
MLS KeyPackages are single-use tokens that enable a group creator to add a new
|
||||
member. The KeyPackage contains the member's HPKE init public key, their MLS
|
||||
credential (Ed25519 public key), and a signature proving ownership. The
|
||||
quicproquo Authentication Service (AS) provides a simple upload/fetch
|
||||
quicprochat Authentication Service (AS) provides a simple upload/fetch
|
||||
interface for distributing KeyPackages between clients.
|
||||
|
||||
**Expiry and refresh:** KeyPackages are consumed on fetch (single-use). The server may also enforce a TTL (e.g. 24h). Clients should upload a fresh KeyPackage periodically or on demand so they remain invitable. The CLI provides `refresh-keypackage`: load existing state, generate a new KeyPackage, upload to the AS. See [Running the Client](../getting-started/running-the-client.md#refresh-keypackage).
|
||||
@@ -12,10 +12,10 @@ This page describes the end-to-end flow: from client-side generation through
|
||||
server-side storage to peer-side retrieval and consumption.
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicproquo-core/src/group.rs` (client-side generation)
|
||||
- `crates/quicproquo-server/src/main.rs` (server-side handlers)
|
||||
- `crates/quicproquo-server/src/storage.rs` (server-side persistence)
|
||||
- `crates/quicproquo-client/src/lib.rs` (client-side RPC calls)
|
||||
- `crates/quicprochat-core/src/group.rs` (client-side generation)
|
||||
- `crates/quicprochat-server/src/main.rs` (server-side handlers)
|
||||
- `crates/quicprochat-server/src/storage.rs` (server-side persistence)
|
||||
- `crates/quicprochat-client/src/lib.rs` (client-side RPC calls)
|
||||
- `schemas/node.capnp` (wire schema)
|
||||
|
||||
---
|
||||
@@ -274,10 +274,10 @@ identity; `register-state` loads from (or initializes) a persistent state file.
|
||||
|
||||
```bash
|
||||
# Ephemeral registration (for testing)
|
||||
qpq register --server 127.0.0.1:7000
|
||||
qpc register --server 127.0.0.1:7000
|
||||
|
||||
# Persistent registration (production)
|
||||
qpq register-state --state alice.bin --server 127.0.0.1:7000
|
||||
qpc register-state --state alice.bin --server 127.0.0.1:7000
|
||||
```
|
||||
|
||||
Output:
|
||||
@@ -292,7 +292,7 @@ KeyPackage uploaded successfully.
|
||||
Fetches a peer's KeyPackage by their hex-encoded Ed25519 public key:
|
||||
|
||||
```bash
|
||||
qpq fetch-key --server 127.0.0.1:7000 7a3f...
|
||||
qpc fetch-key --server 127.0.0.1:7000 7a3f...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Server Hooks
|
||||
|
||||
The `ServerHooks` trait provides a plugin system for extending the quicproquo
|
||||
The `ServerHooks` trait provides a plugin system for extending the quicprochat
|
||||
server. Hooks fire at key points in the request lifecycle — message delivery,
|
||||
authentication, channel creation, and message fetch — allowing you to inspect,
|
||||
log, rate-limit, or reject operations without modifying server internals.
|
||||
@@ -169,7 +169,7 @@ impl ServerHooks for TracingHooks {
|
||||
### Example: payload size limiter
|
||||
|
||||
```rust,ignore
|
||||
use quicproquo_server::hooks::{ServerHooks, HookAction, MessageEvent};
|
||||
use quicprochat_server::hooks::{ServerHooks, HookAction, MessageEvent};
|
||||
|
||||
struct PayloadLimiter {
|
||||
max_bytes: usize,
|
||||
@@ -191,7 +191,7 @@ impl ServerHooks for PayloadLimiter {
|
||||
### Example: login auditor
|
||||
|
||||
```rust,ignore
|
||||
use quicproquo_server::hooks::{ServerHooks, AuthEvent};
|
||||
use quicprochat_server::hooks::{ServerHooks, AuthEvent};
|
||||
|
||||
struct LoginAuditor;
|
||||
|
||||
@@ -210,7 +210,7 @@ impl ServerHooks for LoginAuditor {
|
||||
### Example: composing multiple hooks
|
||||
|
||||
```rust,ignore
|
||||
use quicproquo_server::hooks::*;
|
||||
use quicprochat_server::hooks::*;
|
||||
|
||||
struct CompositeHooks {
|
||||
hooks: Vec<Box<dyn ServerHooks>>,
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Storage Backend
|
||||
|
||||
quicproquo uses two storage backends: `SqlStore` on the server side (SQLCipher-encrypted SQLite with Argon2id key derivation) and `DiskKeyStore` on the client side (bincode-serialised file for MLS cryptographic key material).
|
||||
quicprochat uses two storage backends: `SqlStore` on the server side (SQLCipher-encrypted SQLite with Argon2id key derivation) and `DiskKeyStore` on the client side (bincode-serialised file for MLS cryptographic key material).
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicproquo-server/src/sql_store.rs` (SqlStore)
|
||||
- `crates/quicproquo-server/src/storage.rs` (Store trait, FileBackedStore legacy)
|
||||
- `crates/quicproquo-core/src/keystore.rs` (DiskKeyStore, StoreCrypto)
|
||||
- `crates/quicprochat-server/src/sql_store.rs` (SqlStore)
|
||||
- `crates/quicprochat-server/src/storage.rs` (Store trait, FileBackedStore legacy)
|
||||
- `crates/quicprochat-core/src/keystore.rs` (DiskKeyStore, StoreCrypto)
|
||||
|
||||
---
|
||||
|
||||
@@ -199,7 +199,7 @@ Persistent mode is used for production clients. The key store path is derived fr
|
||||
|
||||
MLS entities MUST use bincode serialisation. The `DiskKeyStore` implements this with a two-layer scheme:
|
||||
|
||||
1. **Inner layer:** Each MLS entity value (`V: MlsEntity`) is serialised using the openmls-required serialisation format. The `DiskKeyStore` in quicproquo uses bincode for MLS entity values, matching the `OpenMlsKeyStore` trait requirements.
|
||||
1. **Inner layer:** Each MLS entity value (`V: MlsEntity`) is serialised using the openmls-required serialisation format. The `DiskKeyStore` in quicprochat uses bincode for MLS entity values, matching the `OpenMlsKeyStore` trait requirements.
|
||||
2. **Outer layer:** The entire `HashMap<Vec<u8>, Vec<u8>>` is bincode-serialised as the file on disk.
|
||||
|
||||
**Important:** Do not use Protobuf or JSON for MLS entities. MLS requires bincode for the `DiskKeyStore` in this codebase. Using a different format will produce incompatible key material.
|
||||
|
||||
Reference in New Issue
Block a user