⌂
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.
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
C / PROPERTIES
ls properties/
Six commitments that distinguish NexusFS from yet another sync engine.
⌬
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.
✦
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.
∑
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.
⇌
QUIC transport
Sync rides on QUIC for NAT traversal, connection migration, and clean resume. The transport is replaceable — the proof layer doesn't care.
◇
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.
D / NUMBERS
bench --suite=core/
No benchmark is published yet for this prototype. Numbers will appear here only with hardware, workload, version and a reproduction command.
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) sibling hashes · 32 B each
verifier
no-std · embeddable
illustrative API sketch · not the exact crate surface
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(); // grows with log₂ N 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.