Bendik LynghaugandClaude Fable 5
1a5071b4ab
CI showed the delivery verification timing out while the push itself succeeded: an observe watch opened while the peer's import is still creating the blob can miss the entry and never report again (locally the import always won the race, so a single complete bitfield arrived and the watch looked fine). Poll with fresh short-lived observe requests instead — every iteration reads the peer's current state, so the race disappears. 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.