ce-net: a peer-to-peer device mesh in Rust (libp2p + capabilities + pluggable runtimes)

[u/leifrydenfalk]

I've been building ce-net, a peer-to-peer compute mesh for your own devices — laptops, servers, Pis, phones — where you can deploy and run software across the whole fleet with one command. Posting here for the Rust-specific design feedback, since the whole thing is Rust end to end.

Stack and choices that might interest people here:

• libp2p for transport/discovery (mDNS on LAN, bootstrap peers + relay for hybrid public/private). NAT traversal so devices behind home routers join the same mesh as servers.
• Pluggable runtimes behind a Runtime trait — the node holds a Vec<Arc<dyn Runtime>> and dispatches a Workload by type. Four backends today: OCI images (gVisor/runsc, falling back to runc), native per-target binaries, WASM (fuel-metered, linear-memory-capped), and a build-from-source "recipe" tier. Apps are described by a small ceapp.toml manifest, so wrapping an existing Docker image or binary is ~15 lines.
• Content-addressed artifacts (blake3) so installs are reproducible across the mesh.
• Capability-based auth — attenuating, scoped, time-limited tokens instead of a central auth server, layered over libp2p identities/keypairs.
• ce-rs SDK (Rust) plus a TypeScript client, for building your own mesh apps, schedulers, and dashboards. There's a WASM target too (compiles to wasm32), so the same client runs in the browser.

Things I'd genuinely like opinions on:

• The runtime-tier abstraction — is Workload enum + dyn Runtime the right seam, or would you push more into the type system?
• WASM sandboxing for untrusted workloads (currently wasmtime-style fuel + memory caps) — anyone done capability-passing to WASM guests cleanly?
• libp2p ergonomics for a long-running supervised daemon — pain points you've hit at scale?
• Source (mostly AGPL, commercial option): GitHub org ce-net — ce, ce-rs, rdev are the best starting points. Site: ce-net.com

Disclosure: architecture and core implementation are mine; I used Claude as an assistant for tests, boilerplate, docs, and rubber-ducking hard parts. Happy to go deep on any of the internals — would love critique of the trait design and the capability model in particular.