Why Ledvar exists

An open protocol for remembering what changed.

If you keep systems running — infrastructure, security, DevOps, SRE — you know this one. A firewall port opened “just for a test” that stays open forever, because everyone forgot. An application nobody uses anymore, still sitting there for months on a machine nobody logs into. A setting loosened at three in the morning during an incident, and never tightened again. None of it is malicious — it is the natural entropy of real systems. It is drift: the environment changes quietly, and the change gets lost in time.

And we all try to hold it back the same way: scripts, checklists, checking by hand. It helps — the drift gets smaller — but it never stops. Because the hard part was never collecting the state. It was remembering it, and comparing it honestly against yesterday’s.

Where it came from

I have administered infrastructure for more than two decades, and this problem followed me the whole way — at my own company and everywhere I worked. I have been a Rust enthusiast for a while, but — like every professional in this field, who also has a life outside work — I never had the time to try to solve this by building a tool made for the purpose. And the knot was never writing code: it was finding a way to normalize how any piece of infrastructure and security information is represented — a firewall rule, a cloud permission, a file, a user, a table — so that things this different could be compared the same way, every time.

That is what unlocked it. I started using AI as a tool: well directed, it speeds the work up enormously and let me test hypotheses at a scale I would never reach alone — shapes, conditions, edge case after edge case, hunting for where my abstraction broke. Hammering on it is how the thing got small and sharp enough to become a protocol: Ledvar.

And it isn’t only about infrastructure

Then came the part I did not expect: what came out is not about infrastructure at all. The protocol does not know — and does not need to know — whether a node describes a firewall rule, a DNS record, a table’s schema, an inventory item, a SaaS subscription, or a blockchain transaction. It only knows how to compare state. If you can write the thing as a tree of nodes, Ledvar remembers it and tells you what moved.

And that is not a promise: the conformance vectors deliberately span a database, a virtual machine, a filesystem, a Bitcoin transaction, a retail product, a DNS record and a SaaS subscription — most of which have nothing to do with infrastructure or security.

What it is — and is not

Ledvar defines nouns, not verbs: what a piece of state is, and how it is hashed. It does not say what to do with it — checking, comparing, storing, alerting and displaying are the business of independent implementations built on top. It is deliberately the smallest thing that lets independent implementations agree, and nothing more.

It is also encoding-agnostic: carry a snapshot as JSON, YAML, XML or Protocol Buffers — the only fixed encoding is the handful of bytes that get hashed.

Two choices

A word on why this is open. Most of my life has been supported by this ecosystem — open tools, open knowledge, people freely sharing what they worked out. It paid my bills and my family’s. Releasing Ledvar this way is the thank-you I am able to give back.

And on why it is a protocol, not a product. Decentralization was something I only half-grasped, by reasoning about it, until Bitcoin showed me how powerful it can be: a thing nobody owns, that anyone can run, verify, and reimplement. I wanted to take that idea at its word. So Ledvar is a contract, not a product — run my implementation, or write your own and ignore mine entirely. If it is useful and it makes sense, take the idea and make it better. Thank you, Satoshi Nakamoto.

The invitation

And you do not have to take my word for any of it. What the protocol produces is verifiable: same input, same hash, byte for byte — the vectors are the proof, run them yourself and compare. How it was made does not change whether it is correct; you check.

So here is the invitation: test it. Reimplement it in your language. Try to break it. Look for the flaw — it probably exists, and finding it is the most useful thing you can do. You help this protocol grow not only by building on it, but by using it and attacking it.

I hope it makes as much sense to you as it did to me.

Where to go from here

• Getting started — install the CLI and run your first hash and diff.
• The specification — the normative protocol.
• Writing a collector — turn real state into a Ledvar snapshot.
• The manifesto — the principles the project commits to.

On GitHub: the protocol — the specification, the conformance vectors and the licence — and ledvar-rs, the Rust reference implementation.

This site is a work in progress. Sections are published as each part of the ecosystem takes shape.