OneSVD
GitHub

The Merkle tree

How OneSVD fingerprints your files and folders, and why a single root hash certifies the whole tree.

A Merkle tree is a tree where every node carries a hash of its contents, and every parent's hash is computed from its children's hashes. OneSVD builds one over your watched directory, which gives you a single number — the root hash — that changes if and only if anything in the tree changes.

How a file is hashed#

Each file's fingerprint is the SHA-256 of its bytes. Two files with identical contents have identical hashes, regardless of name or location — that's content addressing: the hash is the address of the content.

How a folder is hashed#

A folder doesn't hash its own bytes — it has none. Instead its hash is derived from its children. OneSVD takes each child's name, type, and hash, sorts them deterministically, serializes that list, and hashes the result:

text
dir_hash = SHA256( sorted([{name, type, sha256} for each child]) )

Because the inputs are sorted, the same set of children always produces the same folder hash — the order files happen to arrive in doesn't matter.

Why the cascade matters#

Change one byte in one file deep in the tree, and its hash changes. That changes its parent folder's hash, which changes that folder's parent, all the way up to the root. So:

  • If the root hash is unchanged, nothing in the tree changed.
  • If the root hash changed, something did — and you can walk down to find exactly what.
Note:

This is the same structure Git uses for commits and trees, and what IPFS and Certificate Transparency logs use for tamper-evidence. OneSVD applies it to a live directory you control.

Seeing it in the UI#

The root hash sits in the top bar and updates in real time. Click it to open the Merkle graph — root on the left, branching out to folders and files, each labeled with its hash. When a change is in flight you'll see a "recalculating" indicator on the affected nodes until the new hashes land.

What it gives you#

Because the tree is content-addressed, identical content is identical everywhere, and verification is cheap: compare hashes, not bytes. That's the foundation for everything else — sharing a link to a known hash, verifying an artifact a runner built, or (in the future) deduplicating and versioning content across snapshots.

Next#