Eden: The Offline-First, Zero-Telemetry Build System

Eden is a build system that treats privacy and reproducibility as first-class features. Unlike mainstream tools that collect usage metrics, require cloud accounts, or silently depend on network access, Eden runs entirely offline by default. Every build is deterministic: given the same source code and configuration, Eden will produce the exact same outputs, even years later. It achieves this through content-addressable storage (CAS), where every file and build artifact is referenced by its cryptographic hash. The build graph is also hashed, so caching is trivial and trustless.

Eden is not a CI system or a package registry. It is a local tool for individual developers and small teams who want full control over their toolchain. Configuration is a single TOML file (eden.toml) that declares sources, toolchain versions, and build steps. The Eden daemon runs in the background, watching for changes and incrementally rebuilding only what is necessary. Network access is strictly opt-in, and if allowed, it is cached and pinned so that future builds remain reproducible.

Eden is written in Rust for memory safety and performance. The CAS backend is SQLite with a file blob store. Language support is provided by plugins (e.g., eden-rust, eden-python, eden-node) that communicate with the daemon via a simple protocol. The project was prototyped to the point of building a simple Rust project without any network calls, but stalled when the creator joined a startup heavily invested in Bazel.

Modern build systems (Bazel, Buck, Nix) are powerful but complex, often requiring network access for dependency resolution and frequently collecting telemetry. This creates a reliance on external services, undermines reproducibility, and compromises developer privacy. Small projects and individual developers are left with either heavyweight tools that do too much or ad-hoc scripts that do too little. Eden scratches the itch for a lightweight, deterministic, and truly offline build tool that respects the developer's machine as their own.

• Provide a fully offline build pipeline with no mandatory network calls
• Ensure deterministic and reproducible builds via content-addressable storage
• Collect zero telemetry, crash reports, or usage statistics
• Support multiple programming languages through a plugin architecture
• Offer intuitive, minimal configuration with sensible defaults
• Enable incremental builds and fast caching without network dependence

• Not a continuous integration or deployment system
• Not a package registry or package manager (though it can use local mirrors)
• Not a cloud service or SaaS
• Not a community-driven plugin marketplace (plugins are local)
• Not designed for monorepos with thousands of engineers (small teams are the target)

• Core language: Rust (for safety, speed, and cross-platform support)
• Storage: SQLite for metadata, content-addressed file blobs on disk (CAS)
• Plugin protocol: gRPC or custom Unix socket IPC for language-specific runners
• Configuration: TOML for eden.toml; .edenignore files similar to .gitignore
• CLI: clap for command parsing, crossterm for terminal output
• Testing: Rust's built-in test framework, plus integration tests using Docker for reproducibility checks

Eden consists of two main components: a long-running daemon (edend) and a CLI client (eden). The daemon manages the CAS database and caches. The CLI sends requests to the daemon via a local Unix socket (or named pipe on Windows).

Build Definition: An eden.toml file declares sources, dependencies (as local paths or pinned archives), toolchain (e.g., rustc 1.70.0), and build rules. Each rule specifies inputs (source globs, intermediate hashes) and outputs (artifact hashes). The daemon computes a hash of the entire rule combined with inputs, checks the cache, and either returns the cached output or executes the rule.

Content-Addressable Storage: Every file and artifact is stored under its SHA-256 hash. The CAS is an append-only store, ensuring that builds are reproducible and that no data is ever overwritten.

Offline Dependency Resolution: Dependencies are declared either as local directories or as content-hashed tarballs. Eden can optionally download missing tarballs from a user-configured mirror, but the hash is required upfront—no discovery. All downloaded content is cached and pinned.

Plugin System: Language support is provided by separate executables (e.g., eden-rust) that the daemon invokes. They receive a manifest of inputs and output paths and are expected to produce the outputs and return their hashes. The plugin has no access to the network unless granted via a capability flag.

Watch Mode: The daemon can watch the project directory using filesystem events (inotify, kqueue) and trigger rebuilds automatically, with debouncing.

• Performance: Pure offline CAS rebuilds can be slower than tools that fetch remote dependencies. Mitigation: enable optional, user-controlled network mirrors.
• Ecosystem fragmentation: Language plugins may lag behind official tool updates. Mitigation: design plugin interface to be independent of tool versions; allow plugins to wrap existing tools.
• User adoption: Developers may be reluctant to switch from familiar tools. Mitigation: focus on privacy advocates and reproducibility enthusiasts first; provide migration guides from make, Cargo, etc.
• Complexity of deterministic builds: Some languages have non-deterministic outputs (e.g., build timestamps). Mitigation: strip or hash-ignore such metadata by default, with opt-in for full determinism.

• Should we support remote caching (e.g., a local network cache) as an opt-in feature?
• How to handle dependencies that are not content-addressed (e.g., system libraries)?
• Should Eden include a built-in test runner, or delegate entirely to plugins?
• How to handle large binary outputs (e.g., game assets) without bloating the CAS?
• What is the best way to define a 'toolchain version' across platforms?

The creator built a minimal prototype that could compile a single Rust crate without network access, but then took a job at a company that standardized on Bazel. The project was set aside and never revived—not because it was a failure, but because life moved on. It remains a passion idea, waiting for someone with enough time to see it through.

Eden is named after the garden—a self-contained, pristine environment. The mascot is a tree with a padlock. The project's manifesto would be 'No telemetry, no tracking, no phoning home—your build, your data.'