Bendik Aagaard LynghaugandClaude Fable 5.1
08fcba749a
iroh 1.0.2 -> 1.3.0 (relay reconnects that keep answering, rate-limit notices from relays, the n0 DNS resolver with configurable fallbacks, relay connection metrics), iroh-mdns-address-lookup 0.4 -> 0.6, n0-future 0.1 -> 0.3. No code changes were needed; the suite passes. varde.service now keeps /run/varde across restarts (RuntimeDirectoryPreserve=yes): stopping the service removed the directory and with it the socket unit's file, leaving varde.socket "active" on an unlinked path after any service restart. The install notes say to restart the socket, which cycles both. Co-Authored-By: Claude Fable 5.1 <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.