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

10
docs/src/roadmap/production-readiness.md
View File

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