Celerity 0.1.1: pure Rust ZMTP 3.1 with a sans-IO core, Tokio transport, and CURVE-RS
โ Rust ๐ 2026-04-20 ๐ค surdeus ๐๏ธ 3
Info
Hi all,
Iโve been working on celerity, a pure Rust implementation of ZMTP 3.1 for guys who want ZeroMQ-style messaging semantics without really depending on libzmq.
The main design choice is that the protocol engine is sans-IO. CelerityPeer owns greeting, handshake, framing, multipart assembly, and security state, while the optional Tokio layer handles TCP and Unix domain sockets. That split kept the wire protocol testable in isolation and kept transport issues separate from protocol state.
Current scope:
ZMTP 3.1 greeting, handshake, framing, and multipart messages
PUB/SUB and REQ/REP
Tokio transport wrappers for TCP and Unix sockets
CURVE-RS for authenticated/encrypted non-local links
a small cel-cat CLI for local smoke testing
A few implementation details:
Security is scope-aware: loopback TCP and IPC default to NULL for local workflows, while non-local links fail closed unless CURVE is configured or insecure NULL is explicitly enabled.
The CURVE-RS path uses X25519 key agreement, HKDF-SHA256 for derivation, and ChaCha20-Poly1305 for traffic protection.
High-water mark configuration supports either backpressure or DropNewest behavior.
Handshake metadata is case-insensitive on lookup while preserving original bytes on the wire.
The API currently has two layers:
low-level: CelerityPeer as a protocol state machine
higher-level: celerity::io with Tokio adapters and helpers like PubSocket, SubSocket, ReqSocket, and RepSocket
Iโve been validating it with cargo test --all-features; the current test matrix covers handshake edge cases, CURVE flows, IPC authorization checks, queue policy behavior, and end-to-end Tokio socket roundtrips.
Iโd be interested in feedback on:
I'm open to any other suggestions
1 post - 1 participant
๐ท๏ธ Rust_feed