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:
@@ -13,7 +13,7 @@ PCS is the complement of [forward secrecy](forward-secrecy.md):
|
||||
- **Post-compromise security** protects the **future** from a past compromise.
|
||||
|
||||
MLS (RFC 9420) is specifically designed to provide both properties simultaneously
|
||||
for group messaging. This is a key differentiator of quicproquo's design.
|
||||
for group messaging. This is a key differentiator of quicprochat's design.
|
||||
|
||||
## How MLS Provides PCS
|
||||
|
||||
@@ -64,7 +64,7 @@ This means:
|
||||
For a group of 1,000 members, the path length is approximately 10 nodes --
|
||||
making PCS practical even for large groups.
|
||||
|
||||
## Epoch Advancement in quicproquo
|
||||
## Epoch Advancement in quicprochat
|
||||
|
||||
In the current implementation, epoch advancement occurs through the `GroupMember`
|
||||
methods in `group.rs`:
|
||||
@@ -145,7 +145,7 @@ deleted), and future epochs are protected by PCS (new key material generated).
|
||||
|
||||
Signal's group messaging uses **Sender Keys**, a fundamentally different
|
||||
mechanism from MLS's ratchet tree. The comparison is instructive because it
|
||||
highlights why MLS was chosen for quicproquo:
|
||||
highlights why MLS was chosen for quicprochat:
|
||||
|
||||
### Signal Sender Keys
|
||||
|
||||
@@ -168,7 +168,7 @@ security. If an attacker compromises a member's Sender Key:
|
||||
membership changes.
|
||||
- There is no automatic healing mechanism analogous to MLS's ratchet tree.
|
||||
|
||||
### MLS Ratchet Tree (quicproquo)
|
||||
### MLS Ratchet Tree (quicprochat)
|
||||
|
||||
In contrast, MLS's ratchet tree provides PCS because:
|
||||
|
||||
@@ -218,7 +218,7 @@ periodic Updates (planned) will bound the healing window.
|
||||
|
||||
### Server compromise does not prevent PCS
|
||||
|
||||
The quicproquo server is MLS-unaware -- it stores and forwards encrypted
|
||||
The quicprochat server is MLS-unaware -- it stores and forwards encrypted
|
||||
MLS messages without access to the group state. A compromised server cannot:
|
||||
|
||||
- Prevent PCS by blocking Commits (it could perform denial-of-service, but
|
||||
|
||||
Reference in New Issue
Block a user