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>
This commit is contained in:
@@ -9,8 +9,8 @@ This page covers the server-side implementation of KeyPackage storage, the
|
||||
`Auth` struct validation logic, and the hybrid key endpoints.
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicnprotochat-server/src/main.rs` (RPC handlers, auth validation)
|
||||
- `crates/quicnprotochat-server/src/storage.rs` (FileBackedStore)
|
||||
- `crates/quicproquo-server/src/main.rs` (RPC handlers, auth validation)
|
||||
- `crates/quicproquo-server/src/storage.rs` (FileBackedStore)
|
||||
- `schemas/node.capnp` (wire schema)
|
||||
|
||||
---
|
||||
@@ -148,8 +148,8 @@ Configured via CLI flags / environment variables:
|
||||
|
||||
| Flag / Env Var | Default | Purpose |
|
||||
|-----------------------------------|---------|---------|
|
||||
| `--auth-token` / `QUICNPROTOCHAT_AUTH_TOKEN` | None | Required bearer token. If unset, any non-empty token is accepted for version 1. |
|
||||
| `--allow-auth-v0` / `QUICNPROTOCHAT_ALLOW_AUTH_V0` | `true` | Whether to accept `auth.version=0` (legacy, unauthenticated) requests. |
|
||||
| `--auth-token` / `QPQ_AUTH_TOKEN` | None | Required bearer token. If unset, any non-empty token is accepted for version 1. |
|
||||
| `--allow-auth-v0` / `QPQ_ALLOW_AUTH_V0` | `true` | Whether to accept `auth.version=0` (legacy, unauthenticated) requests. |
|
||||
|
||||
### Version Semantics
|
||||
|
||||
|
||||
@@ -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/quicnprotochat-server/src/main.rs` (RPC handlers)
|
||||
- `crates/quicnprotochat-server/src/storage.rs` (queue storage)
|
||||
- `crates/quicproquo-server/src/main.rs` (RPC handlers)
|
||||
- `crates/quicproquo-server/src/storage.rs` (queue storage)
|
||||
- `schemas/node.capnp` (wire schema)
|
||||
|
||||
---
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# GroupMember Lifecycle
|
||||
|
||||
The `GroupMember` struct in `quicnprotochat-core` is the core MLS state machine
|
||||
The `GroupMember` struct in `quicproquo-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/quicnprotochat-core/src/group.rs`
|
||||
**Source:** `crates/quicproquo-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
|
||||
quicnprotochat Authentication Service (AS) provides a simple upload/fetch
|
||||
quicproquo 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/quicnprotochat-core/src/group.rs` (client-side generation)
|
||||
- `crates/quicnprotochat-server/src/main.rs` (server-side handlers)
|
||||
- `crates/quicnprotochat-server/src/storage.rs` (server-side persistence)
|
||||
- `crates/quicnprotochat-client/src/lib.rs` (client-side RPC calls)
|
||||
- `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)
|
||||
- `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)
|
||||
quicnprotochat register --server 127.0.0.1:7000
|
||||
qpq register --server 127.0.0.1:7000
|
||||
|
||||
# Persistent registration (production)
|
||||
quicnprotochat register-state --state alice.bin --server 127.0.0.1:7000
|
||||
qpq 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
|
||||
quicnprotochat fetch-key --server 127.0.0.1:7000 7a3f...
|
||||
qpq fetch-key --server 127.0.0.1:7000 7a3f...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Storage Backend
|
||||
|
||||
quicnprotochat uses two storage backends: `FileBackedStore` on the server side
|
||||
quicproquo uses two storage backends: `FileBackedStore` on the server side
|
||||
for KeyPackages and delivery queues, and `DiskKeyStore` on the client side for
|
||||
MLS cryptographic key material. Both follow the same pattern: in-memory data
|
||||
structures backed by optional file persistence, with full serialization on every
|
||||
write.
|
||||
|
||||
**Sources:**
|
||||
- `crates/quicnprotochat-server/src/storage.rs` (FileBackedStore)
|
||||
- `crates/quicnprotochat-core/src/keystore.rs` (DiskKeyStore, StoreCrypto)
|
||||
- `crates/quicproquo-server/src/storage.rs` (FileBackedStore)
|
||||
- `crates/quicproquo-core/src/keystore.rs` (DiskKeyStore, StoreCrypto)
|
||||
|
||||
---
|
||||
|
||||
@@ -52,7 +52,7 @@ File paths:
|
||||
- `{dir}/hybridkeys.bin` -- Hybrid public keys
|
||||
|
||||
The default data directory is `data/`, configurable via `--data-dir` /
|
||||
`QUICNPROTOCHAT_DATA_DIR`.
|
||||
`QPQ_DATA_DIR`.
|
||||
|
||||
### Flush-on-Every-Write
|
||||
|
||||
@@ -233,7 +233,7 @@ fn keystore_path(state_path: &Path) -> PathBuf {
|
||||
}
|
||||
```
|
||||
|
||||
So `quicnprotochat-state.bin` produces a key store at `quicnprotochat-state.ks`.
|
||||
So `qpq-state.bin` produces a key store at `quicproquo-state.ks`.
|
||||
|
||||
### Persistence Format
|
||||
|
||||
|
||||
Reference in New Issue
Block a user