offline by default
Writes commit locally to the op log first; sync is opportunistic. There is no central server you can lose — every peer is a complete history.
a verifiable, offline-first filesystem. signed ops. deterministic replication. proof-ready.
NexusFS is a filesystem for environments where you can't trust the wire — or the disk. Operations are signed, replication is deterministic, and the on-disk format is designed so any third party can verify that a node hasn't lied about what it stored.
A filesystem that owes you a proof, not a promise.
Most distributed filesystems give you eventual consistency and ask you to trust the disk. NexusFS gives you a deterministic, append-only op log — every write is a signed CRDT operation; every replica converges to the same state; every byte can be challenged with a proof of inclusion.
The design lives at the intersection of three lines of work: CRDTs for conflict-free merge, Merkle accumulators for proof generation, and QUIC for offline-first transport that resumes cleanly across NAT. It's the storage substrate I want under Wardex receipts and SafeDrop deliveries.
An op log, a CRDT view, and a Merkle accumulator. That's it.
Six commitments that distinguish NexusFS from yet another sync engine.
Writes commit locally to the op log first; sync is opportunistic. There is no central server you can lose — every peer is a complete history.
Two forks of the same log converge to the same view, byte-for-byte, regardless of which order operations arrived. CRDT properties are tested, not asserted.
Every op carries an ed25519 signature bound to writer identity. Tampered logs fail verification at the boundary; you don't need to trust the carrier.
A Merkle accumulator over the op log lets any peer answer "did you store this?" with a logarithmic proof. Audits replay; they don't trust.
Sync rides on QUIC for NAT traversal, connection migration, and clean resume. The transport is replaceable — the proof layer doesn't care.
Large objects sit in a content-addressed blob store keyed by BLAKE3. Deduplication is automatic; corruption is local; verification is constant-time.
Synthetic + replay traces on a 2024 M2 Pro, 3 peers across continents in the WAN bench.
A proof of inclusion fits in a struct. So does its verifier.
Every read returns the data and a proof that the store committed to it. Proofs are bytes you can email, store, or post on a noticeboard — anyone with the writer's public key can replay and verify offline.
This is the same surface that makes NexusFS useful as evidence storage for wardex receipts and safedrop deliveries: the producer signs, the store proves, the auditor replays.
src/proof.rs · inclusion proof1use nexusfs::{Store, ProofInclusion, OpId}; 2 3// 1. write — returns a proof of inclusion. 4let store = Store::open("./nexus.dat")?; 5let id: OpId = store.put("docs/handbook.md", payload)?; 6let proof: ProofInclusion = store.prove(id)?; 7 8// 2. proof is bytes — pass it around like any other. 9let bytes = proof.to_bytes(); // avg 17 B 10post_to_auditor(bytes).await?; 11 12// 3. anyone can verify offline. 13use nexusfs_verify::{Verifier, Root}; 14 15let root: Root = latest_signed_root(&writer_pk)?; 16let v = Verifier::new(&writer_pk, root); 17 18match v.check(&proof, &payload_hash) { 19 Ok(()) => println!("✓ included at {}", proof.idx), 20 Err(e) => println!("✗ tamper: {e}"), 21} 22 23// $ nexusfs verify ./bundle.nfs 24// ◆ 1.2M ops · 0 forks · 0 unsigned 25// ◆ root: 9f1a..c204 (signed: pinkysworld) 26// ◆ verified · 82k ops/s · 14.6s total
Eight modules, each with a tight contract. The verifier is the smallest.
From an op-log sketch to a verifier you can hand to anyone.
Four questions worth answering up front.
No. There's no consensus algorithm, no token, no global linearization. NexusFS is local-first per-writer; the Merkle accumulator gives you third-party verifiability without coordinating who writes when.
An auditor or counterparty can prove that a specific file was stored at a specific point in your log — without trusting the server. That matters for evidence (Wardex receipts), regulated workflows, and any system where the carrier is untrusted.
Yes, by design. The CRDT view resolves the merge deterministically; nothing is silently overwritten. Multi-writer policy (whose write wins) is the active design surface.