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:
@@ -1,6 +1,6 @@
|
||||
# Introduction
|
||||
|
||||
**quicproquo** is a research-oriented, end-to-end encrypted group messaging system written in Rust. It layers the Messaging Layer Security protocol (MLS, [RFC 9420](https://datatracker.ietf.org/doc/rfc9420/)) on top of QUIC + TLS 1.3 transport (via [quinn](https://github.com/quinn-rs/quinn) and [rustls](https://github.com/rustls/rustls)), with all service RPCs framed using a compact binary Protocol Buffers format over a custom framing layer. The project exists to explore how modern transport encryption (QUIC), a formally specified group key agreement protocol (MLS), and post-quantum hybrid key encapsulation compose in practice -- and to provide a readable, auditable reference implementation for security researchers, protocol designers, and Rust developers who want to study or extend the design.
|
||||
**quicprochat** is a research-oriented, end-to-end encrypted group messaging system written in Rust. It layers the Messaging Layer Security protocol (MLS, [RFC 9420](https://datatracker.ietf.org/doc/rfc9420/)) on top of QUIC + TLS 1.3 transport (via [quinn](https://github.com/quinn-rs/quinn) and [rustls](https://github.com/rustls/rustls)), with all service RPCs framed using a compact binary Protocol Buffers format over a custom framing layer. The project exists to explore how modern transport encryption (QUIC), a formally specified group key agreement protocol (MLS), and post-quantum hybrid key encapsulation compose in practice -- and to provide a readable, auditable reference implementation for security researchers, protocol designers, and Rust developers who want to study or extend the design.
|
||||
|
||||
---
|
||||
|
||||
@@ -18,9 +18,9 @@
|
||||
|
||||
Each layer addresses a distinct concern:
|
||||
|
||||
1. **QUIC + TLS 1.3** provides authenticated, confidential transport with 0-RTT connection establishment and multiplexed streams. The server presents a TLS 1.3 certificate (self-signed by default); the client verifies it against a local trust anchor. ALPN negotiation uses the token `qpq`.
|
||||
1. **QUIC + TLS 1.3** provides authenticated, confidential transport with 0-RTT connection establishment and multiplexed streams. The server presents a TLS 1.3 certificate (self-signed by default); the client verifies it against a local trust anchor. ALPN negotiation uses the token `qpc`.
|
||||
|
||||
2. **Protobuf framing** defines the wire format for all service operations across 44 RPC methods. Each request carries a `[method_id: u16][request_id: u32][payload_len: u32]` header followed by a Protobuf-encoded payload. Server-to-client push events use a separate frame type on QUIC uni-streams. Message definitions live in `proto/qpq/v1/*.proto` and are compiled to Rust with `prost` at build time.
|
||||
2. **Protobuf framing** defines the wire format for all service operations across 44 RPC methods. Each request carries a `[method_id: u16][request_id: u32][payload_len: u32]` header followed by a Protobuf-encoded payload. Server-to-client push events use a separate frame type on QUIC uni-streams. Message definitions live in `proto/qpc/v1/*.proto` and are compiled to Rust with `prost` at build time.
|
||||
|
||||
3. **MLS (RFC 9420)** provides the group key agreement layer. Each participant holds an Ed25519 identity keypair and generates single-use HPKE KeyPackages. The MLS epoch ratchet delivers forward secrecy and post-compromise security: compromising a member's state at epoch *n* does not reveal plaintext from epochs *< n* (forward secrecy) or *> n+1* (post-compromise security, once the compromised member updates).
|
||||
|
||||
@@ -53,12 +53,12 @@ For a deeper discussion of the cryptographic guarantees, threat model, and known
|
||||
|
||||
**Security researchers** studying how MLS composes with QUIC transport and post-quantum hybrid KEM. The codebase spans 9 workspace crates with clear cryptographic boundaries for auditability.
|
||||
|
||||
**Protocol designers** evaluating MLS deployment patterns. quicproquo implements a concrete Authentication Service (AS) and Delivery Service (DS) pair, demonstrating single-use KeyPackage lifecycle, Welcome routing, and epoch advancement in a live system.
|
||||
**Protocol designers** evaluating MLS deployment patterns. quicprochat implements a concrete Authentication Service (AS) and Delivery Service (DS) pair, demonstrating single-use KeyPackage lifecycle, Welcome routing, and epoch advancement in a live system.
|
||||
|
||||
**Application developers** building on the platform via the Rust SDK:
|
||||
|
||||
- **`quicproquo-sdk`** -- `QpqClient` with async event streams and a `ConversationStore`
|
||||
- **C FFI** -- cross-language integration via `quicproquo-plugin-api`
|
||||
- **`quicprochat-sdk`** -- `QpqClient` with async event streams and a `ConversationStore`
|
||||
- **C FFI** -- cross-language integration via `quicprochat-plugin-api`
|
||||
|
||||
**Rust developers** looking for a working example of:
|
||||
|
||||
@@ -73,7 +73,7 @@ For a deeper discussion of the cryptographic guarantees, threat model, and known
|
||||
|
||||
| Section | What you will find |
|
||||
|---|---|
|
||||
| **[Comparison with Classical Protocols](design-rationale/protocol-comparison.md)** | **Why quicproquo? IRC+SSL, XMPP, Telegram vs. our design** |
|
||||
| **[Comparison with Classical Protocols](design-rationale/protocol-comparison.md)** | **Why quicprochat? IRC+SSL, XMPP, Telegram vs. our design** |
|
||||
| [Prerequisites](getting-started/prerequisites.md) | Toolchain and system dependencies |
|
||||
| [Building from Source](getting-started/building.md) | `cargo build`, Protobuf codegen, troubleshooting |
|
||||
| [Running the Server](getting-started/running-the-server.md) | Server startup, configuration, TLS cert generation |
|
||||
@@ -90,7 +90,7 @@ For a deeper discussion of the cryptographic guarantees, threat model, and known
|
||||
|
||||
## Current status
|
||||
|
||||
quicproquo is a **research project** with production-grade features. It has
|
||||
quicprochat is a **research project** with production-grade features. It has
|
||||
not been audited by a third party. The test suite covers 301 tests across
|
||||
core, server, client, E2E, and P2P modules.
|
||||
|
||||
@@ -120,4 +120,4 @@ For the full milestone tracker, see [Milestones](roadmap/milestones.md).
|
||||
|
||||
## License
|
||||
|
||||
quicproquo is released under the **MIT** license. See `LICENSE` in the repository root.
|
||||
quicprochat is released under the **MIT** license. See `LICENSE` in the repository root.
|
||||
|
||||
Reference in New Issue
Block a user