// the find
eclipse-zenoh/zenoh
zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.
Zenoh is a Rust-native pub/sub + storage + query protocol designed for constrained environments, edge/IoT, and robotics (heavy ROS2 usage). It operates broker-optional, supports peer-to-peer and routed topologies, and is notably used as a DDS alternative in the ROS2 ecosystem. The target audience is embedded/edge developers, roboticists, and anyone who finds MQTT or DDS too heavy or too centralized.
- Protocol design is genuinely thoughtful: wire expressions compress key names, varint encoding throughout, and shared memory support (opt-in) for zero-copy intra-host messaging — not just marketing claims, the codec crate is well-structured and fuzz-tested.
- Multi-language bindings (C, C++, Python, Kotlin, Java, TypeScript) are first-class via zenoh-c/zenoh-pico, and zenoh-pico is a pure-C implementation for microcontrollers — meaning you can run the same protocol from a Cortex-M to a cloud node.
- CI is solid: valgrind checks, fuzz targets on codec and protocol layers, nostd compatibility checks, and a separate pinned-deps crate for Rust 1.75 compatibility — this is more than most open-source infra projects bother with.
- Eclipse dual-licensing (EPL-2.0 + Apache-2.0) is a practical choice that unblocks commercial use without the GPL friction you get from other Eclipse projects.
- The internal crates (commons/*) explicitly document their APIs as unstable and subject to change at any time, which makes building plugins or extensions fragile — you're one release away from breakage with no semver protection.
- Storage and persistence are handled by external plugins rather than being built-in, and the plugin ecosystem is small and scattered across separate repos with inconsistent maintenance status. If you need durable storage you're essentially on your own.
- The configuration system (DEFAULT_CONFIG.json5) is sprawling and underdocumented — tuning transport parameters, QoS, connection retry behavior, and SHM requires reading source code since the config docs lag behind the actual implementation.
- TypeScript support is WebSocket-only via a router plugin, not a native protocol implementation — so browser/Node clients are second-class citizens with a hard dependency on running zenohd as a proxy.