minh@systems | ~/showcase/nexusfs | prototype · v0.1.0
read · 10 min | --:--:-- UTC
research v0.1.0 prototype · verifier CLI in flight

nexusfs.

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 / ABSTRACT

cat README.md/

A filesystem that owes you a proof, not a promise.

Abstract · 2026

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.

filesystemCRDTmerkleQUICsigned opsoffline-firstdeterministic replication
B / ARCHITECTURE

tree -L 2/

An op log, a CRDT view, and a Merkle accumulator. That's it.

fig.01 · op flow
nexusfs v0.1.0 · proof-ready
writer ↘ log
verifier ↗ proof
writer
signed ops
ed25519 · monotonic
peer
QUIC transport
offline-first · resume
core
op log
append-only · CRDT
view
CRDT projection
deterministic merge
proof
merkle accumulator
inclusion · exclusion
verifier
third party CLI
replay · challenge
storage
content-addressed
blake3 · blobstore
fig.01 writer → op log → CRDT projection + merkle accumulator · verifier replays
C / PROPERTIES

ls properties/

Six commitments that distinguish NexusFS from yet another sync engine.

01 / 06

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.

local-first · no single point of failure
02 / 06

deterministic merge

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.

CRDT · convergence-tested · property-based
03 / 06

signed operations

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.

ed25519 · writer-bound · cheap to verify
04 / 06

proofs of inclusion

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.

merkle · O(log n) proof · third-party verifiable
05 / 06

QUIC transport

Sync rides on QUIC for NAT traversal, connection migration, and clean resume. The transport is replaceable — the proof layer doesn't care.

QUIC · resume · transport-agnostic proof
06 / 06

content-addressed blobs

Large objects sit in a content-addressed blob store keyed by BLAKE3. Deduplication is automatic; corruption is local; verification is constant-time.

BLAKE3 · CAS · auto-dedup
D / NUMBERS

bench --suite=core/

Synthetic + replay traces on a 2024 M2 Pro, 3 peers across continents in the WAN bench.

op append
0.4ms
signed op → local log committed.
ed25519 · m2 pro
merkle proof
17b
avg proof size per inclusion at 1M ops.
log₂(N) · BLAKE3
WAN sync
3.1s
100k op delta · 3 peers · transcontinental.
QUIC 1-RTT resume
verifier replay
82k/s
ops verified per second on the CLI.
single core · sig-batched
E / PROOF

cat proof.rs/

A proof of inclusion fits in a struct. So does its verifier.

proofs as first-class values

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.

signature
ed25519 · 64 B
hash
BLAKE3 · 32 B
proof size
O(log₂ N) · ~17 B avg
verifier
no-std · embeddable
src/proof.rs · inclusion proof
1use 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
F / COMPONENTS

ls components//

Eight modules, each with a tight contract. The verifier is the smallest.

#namesummarystatus
01
core.oplogappend-only
Signed, ordered, durable op log. Foundation of everything else.
stable
02
crdt.viewprojection
Deterministic CRDT projection over the op log. Tested with property checks.
stable
03
merkle.accaccumulator
Logarithmic inclusion proofs. Exclusion proofs are the in-flight work item.
beta
04
cas.blobBLAKE3
Content-addressed blob store. Auto-dedup, lazy GC, constant-time verify.
stable
05
net.quictransport
QUIC transport with NAT traversal and connection migration.
stable
06
sync.deltaresumable
Delta sync with bloom-style negotiation; resumes cleanly from any cut.
beta
07
verify.clino-std
Third-party verifier CLI; embeddable as a library (no_std friendly).
beta
08
mount.fuseposix view
FUSE adapter so the CRDT view appears as a normal directory tree.
draft
G / ROADMAP

git log --quarters/

From an op-log sketch to a verifier you can hand to anyone.

Q2 · 2025
op log sketch + ed25519
first CRDT projection
naive sync
Q3 · 2025
BLAKE3 CAS blobstore
merkle accumulator v0
property-test harness
Q4 · 2025
QUIC transport
delta sync
WAN bench rig
Q1 · 2026
verifier CLI alpha
exclusion proof draft
no-std verifier crate
Q2 · 2026 — now
verifier CLI 1.0
FUSE mount adapter
wardex receipt sink
Q4 · 2026
exclusion proofs stable
multi-writer fork policy
0.5 cut · pilot use
H / FAQ

cat faq.md/

Four questions worth answering up front.

q · 01

is this a blockchain?

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.

q · 02

what does "verifiable" actually buy me?

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.

q · 03

can two writers fork the same path?

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.

q · 04

relationship to wardex / skeindb?

NexusFS is the storage substrate. Wardex emits signed response receipts that need a verifiable home; SkeinDB's deterministic replication track will read this CRDT projection. The verifier CLI is shared.