c/quicproquo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: rename quicproquo → quicprochat in docs, Docker, CI, and packaging

Browse Source 
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:
Christian Nennemann
2026-03-07 18:46:43 +01:00
parent a710037dde
commit 2e081ead8e
179 changed files with 1645 additions and 1645 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/src/internals/keypackage-exchange.md
View File

@@ -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...
```
---