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: the sans-IO API shape the local vs non-local security defaults missing ZMTP patterns or interoperability cases worth prioritizing next I'm open to any other suggestions Repo: GitHub - ShemShadrack/celerity: Pure Rust sans-IO ZMTP 3.1 engine with Tokio TCP/IPC transport and CURVE-RS · GitHub 1 post - 1 participant Read full topic