No description
| Filename | Latest commit message | Latest commit date |
|---|---|---|
JMARyA
220c98f538
A deposit lays a fixed snapshot out at a path and keeps it there. The snapshot is the truth and the directory its copy; anything that differs is drift, which a survey reports and the deposit's policy undoes: keep (snapshot the drift onto deposits/<name>, then restore; the default, so nothing is ever lost), restore, or alert. - A deposit's snapshot is named by a ref in a new per-state namespace, refs/states/<uuid>/deposits/<name>, so gc roots it like a branch and its reflog makes a move undoable. The namespace is in both gc's mark and reflog expiry; both are mutation-proven. - A bare branch is refused: a deposit holds fixed bytes. Tags, ids and branch^0 are accepted. - Fast surveys trust size + mtime (deposits are written with the snapshot's mtimes) and compare bytes only where those moved; --deep reads everything and catches bit rot. - Repairs are per-file atomic (stage + rename). Foreign content is refused unless --adopt, which keeps it first. Paths overlapping the node are refused. - CLI: ore deposit add|list|check|tend|restore|move|remove. - NixOS: services.ore.deposits.<name> — a fail-closed boot unit that still comes up offline when the bytes are local, plus fast and deep survey timers. nix/tests/deposit.nix covers every policy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
| .moira/envs | ||
| .pi | ||
| crates | ||
| docs | ||
| nix | ||
| openspec | ||
| todo | ||
| .envrc | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
| shell.nix | ||
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.
- Web console —
ore-web, a browser view of a running daemon.
Crates
ore-core—Nodefaçade over store, state, refs, fs, sync, and crypto.ore-cli— theorecommand.ore-daemon—ored, the HTTP API / sync / metrics process.ore-webui—ore-web, a server-rendered console; a client ofored, not part of it.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 init # make ./.ore — a node, holding no states yet
ore state create notes # a state owns no directory
mkdir data
echo hello > data/note.txt
ore snapshot notes --from data -m first
echo world >> data/note.txt
ore snapshot notes --from data -m second
ore log notes # two snapshots on `main`
ore diff notes main~1 main # what the second one changed
ore ls notes # read the state in place
ore cat notes note.txt --ref main~1 # ...at any point in its history
ore restore notes main~1 old # project the first one back out
ore node fsck # rehash every object