Stax Digital Garden

TND-1010 - The Tender Daemon Roadmap

4 min read

Living Document Notice
Published 2026-11-04. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.

The Tender Daemon Roadmap

The Tender Daemon Roadmap: Deep crimson P22R ruby red vector CRT macro showing multi-tiered orbital telemetry rings and radial vector beams

Summary

Building personal knowledge infrastructure requires long-term architectural stability. While many developer utilities suffer from dependency bloat and shifting runtime requirements, the Tender daemon follows a deliberate engineering roadmap focused on static compilation, minimal resource consumption, and multi-vault concurrency.

This roadmap establishes engineering milestones for compiling zero-dependency Rust binaries, enabling headless deployments on low-power edge appliances, and orchestrating multiple disconnected vaults within a single background process. These goals ensure durable execution across varied hardware environments.

Phased Engineering Milestones

The Tender daemon serves as the local transport backbone for the Bosun PKM Tools network. Engineering priorities emphasize deterministic performance, platform portability, and memory safety over speculative feature additions.

Development follows three structured architectural phases:

+--------------------------------------------------------------------+
|                   Tender Daemon Development Phases                 |
|                                                                    |
|  Phase 1: Core Daemon & Static Toolchain                           |
|  - Static compilation targeting musl libc on Linux and x86/ARM     |
|  - Zero dynamic runtime dependencies                               |
|  - Binary footprint restricted to < 10 Megabytes                   |
|                                                                    |
|  Phase 2: Multi-Vault Concurrency                                  |
|  - Single daemon orchestrating isolated vaults                     |
|  - Per-vault write-ahead journals and debounce timers              |
|  - Distinct IPC socket endpoints per workspace                     |
|                                                                    |
|  Phase 3: Edge Appliance Deployments                               |
|  - Headless execution on Raspberry Pi and home NAS hardware        |
|  - Low-power background synchronization daemon                     |
|  - Compact UDP telemetry streaming to Crows Nest collectors        |
+--------------------------------------------------------------------+

Each phase preserves backward compatibility with existing plain-text markdown directories and local-first workflows.

Deliverables and Technical Verification Gates

Milestones define concrete technical deliverables and automated verification gates before code merges into production releases:

VersionMilestone TargetPrimary DeliverableVerification Criteria
v0.2Static Binary ToolchainMusl-linked binary for Linux / macOSStatic link check: ldd tender returns “not a dynamic executable”
v0.3Multi-Vault EngineConcurrent multi-directory watch supervisorZero cross-vault event leakage across 10 concurrent vaults
v0.4Low-Power Edge ModeHeadless service profile for ARMv7/ARM64RSS memory ceiling strictly under 15MB under 100K files
v0.5P2P Direct TransportLocal network peer-to-peer sync protocolDirect sync over LAN without cloud coordination

Cargo workspace configurations enforce static linking and link-time optimization (LTO) across production builds:

[profile.release]
opt-level = 3
lto = "fat"
codegen-units = 1
panic = "abort"
strip = "symbols"
 
[target.x86_64-unknown-linux-musl]
rustflags = ["-C", "target-feature=+crt-static"]
 
[target.aarch64-unknown-linux-musl]
rustflags = ["-C", "target-feature=+crt-static"]

Compiling against musl libc produces self-contained binaries that execute without external system library dependencies, running reliably on older Linux distributions and minimal container environments.

Multi-Vault Orchestration Architecture

Individual knowledge workers frequently maintain multiple vaults: personal journals, client project notes, and public digital gardens. Running a separate daemon process for each vault wastes system resources through duplicated runtime overhead.

The upcoming multi-vault engine introduces a supervisor model that coordinates multiple vaults within a single process:

pub struct VaultConfig {
    pub vault_id: String,
    pub path: PathBuf,
    pub debounce_ms: u64,
    pub sync_target: Option<String>,
}
 
pub struct TenderSupervisor {
    pub vaults: HashMap<String, VaultWorkerHandle>,
}
 
impl TenderSupervisor {
    pub fn mount_vault(&mut self, config: VaultConfig) -> Result<(), SupervisorError> {
        let handle = VaultWorkerHandle::spawn(config)?;
        self.vaults.insert(config.vault_id, handle);
        Ok(())
    }
}

Each mounted vault receives an isolated worker thread, a dedicated write-ahead journal, and an independent inotify watch descriptor. If an unhandled error occurs within one vault worker, the supervisor isolates the failure without impacting neighboring vaults.

Edge Appliance Deployments

Deploying Tender onto home servers, NAS hardware, and Raspberry Pi appliances enables continuous background synchronization without keeping workstations powered on.

Building the static target for ARM architectures verifies low-power operation:

# Compile static release binary for 64-bit ARM edge devices
cargo build --target aarch64-unknown-linux-musl --release
 
# Verify binary has zero dynamic dependencies
file target/aarch64-unknown-linux-musl/release/tender

The resulting binary executes under systemd on edge appliances, consuming under 1% CPU utilization while providing continuous synchronization services across local networks.

  • Directus Target: tender
  • Garden Source Reference: Tender Static Toolchain, Multi-Vault Orchestration, Bosun 2027 Vision, MOC - Ingestion & Capture, MOC - Local-First Systems and Synchronization, MOC - Bosun PKM Tools

Graph View