February 2026

The origin of St. Valentine is most probably related to at least three different Saint Valentinus, all of them martyred on February 14th around the 3rd century AD during Roman persecutions. Valentinus of Rome was a priest executed under Claudius II because he secretly married young couples in spite of the emperor's ban — Claudius thought that married young men did not make good soldiers. Saint Valentinus of Terni was martyred around 273 AD for refusing to renounce his faith and for converting others.

In Roman times, the Lupercalia purification and fertility festival was roughly between the 13th and 15th of February, involving animal sacrifice, ritual running, and other activities meant to promote fertility. Many historians think the Church's institution of Saint Valentine's feast near this date helped absorb or displace Lupercalia.

The meaning of this celebration has evolved: from Roman fertility themes, to Christian faithful self-sacrificing love, to contemporary romantic attachment. I remain attached to the interpretation of Saint Valentine as faithful, self-sacrificing love.

Around 2009–2010, while serving as PrismTech's CTO and co-chairing the OMG DDS Special Interest Group (as one of its founding members), I was working on some of the earliest Extremely Large Scale Systems — deployments spanning military, aerospace, and Smart City infrastructure.

Working on these systems made it crystal clear that DDS would not scale as-is. The problem wasn't just scaling out — it was also scaling down. DDS was not designed to target constrained hardware nor constrained networks.

Other protocols like CoAP worked best integrating small devices with web applications in IoT scenarios, but were still cloud-centric and client/server in nature. MQTT, popularised by IBM as the "holy grail of IoT," had a broker-based approach that suits applications relying on a cloud broker but is problematic for high performance and low latency — especially when spatial locality can be exploited. The MQTT paradox: even two devices sitting on the same network talk through a broker sitting on a cloud thousands of kilometres away.

DDS and other Pub/Sub technologies had brought location transparency for data in motion. But once data was stored, that transparency vanished — forcing everything onto centralised cloud storage. This model does not work for low-latency access, applications that cannot guarantee cloud connectivity, or infrastructure-less deployments.

Back in those days, large-scale cloud-to-microcontroller systems were duct-taped together by assembling a series of protocols, each of which could work on a given system segment. I call this the Digital Frankenstein era.

My discomfort with this way of building systems grew unbearable. I started working on a new protocol that could work efficiently from the microcontroller up to the data-centre, impose no topological constraints, and provide unified abstractions for data in motion (pub/sub) and data at rest (distributed queries).

Mainstream protocols implementing Pub/Sub took one of two approaches: peer-to-peer (assuming each peer can directly communicate with every other peer) or broker-based. Flat P2P networks like DDS don't scale; brokered systems are too fragile with respect to loss of connectivity and not suitable for high performance.

Eventually it became clear that the same abstraction used for wells of data also applies to computations — giving Zenoh its third pillar: location-transparent computations.

I am Sicilian. Growing up in Sicily, I was immersed in the legacy of ancient Greek philosophy — Archimedes from Syracuse, Plato's visits, the pre-Socratics. I was particularly drawn to Zeno of Elea, whose paradoxes of infinity fascinated me from childhood.

Stoicism — founded in Athens by Zenon of Citium — left an equally deep mark on me through Marcus Aurelius' Meditations.

The name Zenoh thus references two philosophers: Zeno of Elea (pre-Socratic, paradoxes of infinity) and Zenon of Citium (Stoic founder). It also stands for ZEro Network OverHead.

The difference between Zenon and Zenoh is less than a letter — it is just the overshoot of the "h".

The next release will come with improvements, some stabilised APIs, and the initial drop of regionalisation.

Regionalisation generalises Zenoh routing from a two-level system to an arbitrary number of routing regions. Currently all routers belong to the same link-state domain, meaning the routing state space scales linearly in the number of routers. The new model: every Zenoh runtime can operate like a gateway with a north and a south side. The routing mechanisms used in the north and south are independent, and this basic mechanism can be used to create an arbitrary number of routing regions.

Planned for the second half of 2026. Features being considered:

• Zenoh-ID based routing — Native support for routing toward a specific Zenoh runtime identified by a given zenoh-id. Helps make admin-space queries more efficient and provides an alternative to breadcrumbs for routing replies.
• Session Establishment — A new session establishment handshake that reduces traffic and reduces the time to establish and re-establish a session.
• Code Simplification — Roll the protocol implementation of zenoh-nostd into mainstream Zenoh, sharing the same crates.
• Configuration Refactoring — Simplify and address existing inconsistencies in Zenoh's configuration.
• Protocol Improvements — Additional protocol improvements addressing different aspects.

Originally in Zenoh there were no constraints on the keys returned by a queryable when responding to a given query. A few years ago it was decided to constrain, by default, the replies of a queryable to be key/values whose keys must match the key expression portion of the query.

However, there are valid use cases where you don't want this constraint — for example, a key (re)mapper service or anything that translates keys. This API has been unstable for some time but will be stabilised in v1.8.0:

let mut builder = z
    .get("bar/baz/one")
    .accept_replies(zenoh::query::ReplyKeyExpr::Any)
    .wait()?;

You can control when issuing a query whether you accept replies that don't match the query key. No changes are required on the queryable side.