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

20
docs/src/protocol-layers/capn-proto.md
View File

@@ -1,6 +1,6 @@
# Protobuf Framing
quicproquo v2 uses a custom binary framing protocol layered over QUIC bidirectional streams. Message payloads are serialised with Protocol Buffers (Protobuf) via the `prost` crate. The framing layer (implemented in `quicproquo-rpc`) adds a compact fixed-size header that carries the method ID, request correlation ID, and payload length -- enabling zero-copy dispatch without a separate length-delimited codec.
quicprochat v2 uses a custom binary framing protocol layered over QUIC bidirectional streams. Message payloads are serialised with Protocol Buffers (Protobuf) via the `prost` crate. The framing layer (implemented in `quicprochat-rpc`) adds a compact fixed-size header that carries the method ID, request correlation ID, and payload length -- enabling zero-copy dispatch without a separate length-delimited codec.
This page covers the three frame types, the method ID dispatch table, status codes, push event delivery, and the Protobuf schema organisation.
@@ -105,7 +105,7 @@ The `status` byte in a Response frame carries one of the following values:
## Method IDs
All 44 RPC method IDs are defined in `crates/quicproquo-proto/src/lib.rs` in the `method_ids` module. The numeric ranges group related methods by service category.
All 44 RPC method IDs are defined in `crates/quicprochat-proto/src/lib.rs` in the `method_ids` module. The numeric ranges group related methods by service category.
### Auth (100-103)
@@ -230,7 +230,7 @@ All 44 RPC method IDs are defined in `crates/quicproquo-proto/src/lib.rs` in the
## Push Event Types
Server-to-client push events are delivered on QUIC uni-streams using the Push frame format. Event types are defined alongside method IDs in `quicproquo-proto/src/lib.rs`:
Server-to-client push events are delivered on QUIC uni-streams using the Push frame format. Event types are defined alongside method IDs in `quicprochat-proto/src/lib.rs`:
| Value | Event | Description |
|-------|-------|-------------|
@@ -261,7 +261,7 @@ This allows many concurrent RPCs on a single QUIC connection without head-of-lin
## Protobuf Schema Organisation
All message types are defined in `proto/qpq/v1/`:
All message types are defined in `proto/qpc/v1/`:
| File | Contents |
|---|---|
@@ -280,22 +280,22 @@ All message types are defined in `proto/qpq/v1/`:
| `p2p.proto` | P2P endpoints, health |
| `federation.proto` | Cross-server relay |
All `.proto` files use `package qpq.v1;` and are compiled to Rust at build time using `prost-build` via the `quicproquo-proto` crate's `build.rs`. The `protobuf-src` crate vendors `protoc`, so no system-wide `protoc` installation is required.
All `.proto` files use `package qpc.v1;` and are compiled to Rust at build time using `prost-build` via the `quicprochat-proto` crate's `build.rs`. The `protobuf-src` crate vendors `protoc`, so no system-wide `protoc` installation is required.
Generated Rust types are accessed via:
```rust
use quicproquo_proto::qpq::v1::{EnqueueRequest, FetchResponse, /* ... */};
use quicproquo_proto::method_ids::{ENQUEUE, FETCH, /* ... */};
use quicprochat_proto::qpc::v1::{EnqueueRequest, FetchResponse, /* ... */};
use quicprochat_proto::method_ids::{ENQUEUE, FETCH, /* ... */};
```
---
## Design Constraints of `quicproquo-proto`
## Design Constraints of `quicprochat-proto`
The `quicproquo-proto` crate enforces three constraints:
The `quicprochat-proto` crate enforces three constraints:
1. **No crypto**: Key material never enters this crate. All encryption and signing happens in `quicproquo-core`.
1. **No crypto**: Key material never enters this crate. All encryption and signing happens in `quicprochat-core`.
2. **No I/O**: Callers own the transport. This crate only converts between bytes and types.
3. **No async**: Pure synchronous data-layer code. Async is the caller's responsibility.