Ore

Ore is a prototype state system: persistent data is stored as versioned,
content-addressed state, and backups, archives, sync, materialization, and future
filesystem views all sit on that one model.

Node  -> State -> Branch -> Snapshot -> Tree -> Entry

The important rule is:

data       = immutable, content-addressed objects
references = mutable, named branch/tag pointers

A .ore/ directory is a node: a sovereign machine identity plus one opaque
object store. A node can hold many states. A state owns no directory; you
snapshot a directory into a state and materialize or checkout a state back
out to a directory.

Where to start

• User-facing docs — mental model, use cases, CLI, Nix, monitoring.
• Architecture notes — design rationale, format, roadmap.
• CLI reference — commands that exist today.

Crates

• ore-core — Node façade over store, state, refs, fs, sync, and crypto.
• ore-cli — the ore command.
• ore-daemon — ored, the HTTP API / sync / metrics process.
• ore-store — opaque content-addressed store, loose objects, packs, indexes.
• ore-state — snapshots, refs, history walking, diff/merge glue, fsck.
• ore-object — canonical object model and serialization.
• ore-fs — directory ingest and materialization.
• ore-chunk — content-defined chunking.
• ore-crypto — per-state encryption and key wrapping.
• ore-diff, ore-merge — pluggable content diff/merge drivers.
• ore-id, ore-encoding — content IDs and wire primitives.

Quick sketch

cargo build

ore node init
mkdir data
echo hello > data/note.txt
ore snapshot default --from data -m first
ore log default
ore restore default main restored