Bendik LynghaugandClaude Fable 5
b53b5cc000
CI (run 208) showed the Push RPC hanging past the test client's 120s
read timeout: endpoint.connect and the delivery-verification observe
loop had no bounds, so a wedged path hung the socket instead of
failing. Connect now times out at 30s and each observe step at 60s,
producing structured errors that name the stage.
The checkout action is back out: run 212 proved the failure is not the
action's version — the runner execs the action's JS with node inside
the job container, and rust:1 has no node ('exec: "node": executable
file not found'). Plain git needs nothing the container lacks.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
varde
A small, boring, distro-packageable Linux daemon that owns a content-addressed blob store and mirrors content between consenting peers, built on iroh (iroh 1.0, iroh-blobs 0.103). Applications talk to it over a unix socket: "add this path", "pin this hash", "materialize hash X at path Y". Think: what Windows Delivery Optimization is for updates — generalized, open, legible.
varde (Norwegian): a stone cairn used as a waypoint.
Design ethos
- Infrastructure, not product. No GUI, no self-updater. A daemon, a CLI, a JSON-lines socket protocol, man pages, systemd units.
- Legible to the network. Identifiable mDNS advertisement, DSCP CS1 marking, conservative rate limits (10 MiB/s up default), LAN-only with zero WAN upload by default, all transfers stop on metered connections.
- Consent-tiered. Discovery is open; replication is explicit.
Content is served only to allowlisted peers, except what you
deliberately publish (
--open-lanpins, exported tickets). All fetched data is BLAKE3-verified regardless — trust gates participation, not integrity.
Layout
| crate | role |
|---|---|
varde-proto |
wire types for the socket API (serde, no I/O) |
varde-daemon |
the service: store, endpoint, policy, socket server |
varde-ctl |
CLI client and protocol reference implementation |
dist/ holds systemd units (system + user, socket activation),
scdoc man pages, an example config, and an untested Arch PKGBUILD.
docs/ has per-milestone decision notes and the redoal integration
sketch.
Quick start
$ varde-daemon --user &
$ varde-ctl add ~/dataset -r
added 5b1c…e0 (1234567 bytes)
$ varde-ctl pin 5b1c…e0
$ varde-ctl ticket export 5b1c…e0 # hand this to another machine
$ varde-ctl ticket import <ticket> # ...which runs this
$ varde-ctl materialize 5b1c…e0 /srv/dataset # reflinks when possible
Trusted peers on the same LAN sync overlapping pins automatically:
$ varde-ctl status # shows this daemon's node id
$ varde-ctl peer trust <node-id-of-the-other-machine> # on both ends
Trusted peers can also hand content to each other directly, no ticket round-trip — the receiver pins what it accepted:
$ varde-ctl push 5b1c…e0 <node-id-of-the-other-machine>
Building and testing
$ cargo build --release
$ cargo test --workspace # spawns real daemons; no mocked iroh
$ cargo clippy --workspace --all-targets -- -D warnings
The metered feature (default on) needs D-Bus at runtime only; build
with --no-default-features for systems without it.
Releasing
$ cargo release # tag + push the current version as-is
$ cargo release patch # or minor / major to bump first — release.toml
This bumps the workspace version, tags vX.Y.Z, and pushes; the tag
triggers .gitea/workflows/release.yml, which builds x86_64 and
aarch64 Linux tarballs (binaries, systemd units, man pages, example
config) and attaches them to the Gitea release.