Summary: WNFS is best understood not as another content-addressed storage backend or sync layer, but as a filesystem specification that separates public state from a private encrypted dark forest while still allowing untrusted storage providers to validate writes. Its reusable mechanism is the combination of versioned file history, CRDT-style mergeability, name-accumulator addressing, skip-ratchet time-scoped access, and asynchronous share payloads that can carry both decryption secrets and UCAN-based write authority. That makes WNFS a useful comparison class for IPFS/Filecoin-adjacent storage stacks, local-first app data layers, and crypto projects claiming user-owned data without making metadata leakage, key distribution, or write-validation surfaces explicit.
What it does:
Defines a suite of specs for public WNFS, private WNFS, shared private data, name accumulators, and skip ratchets
Models filesystem state as versioned, logged, content-addressed data that can be merged as a state-based CRDT for offline collaboration
Separates a simpler public branch from a private encrypted branch whose structure is hidden inside a HAMT-based PrivateForest
Lets devices partially load a filesystem and still make writes, which matters for edge and browser-constrained environments
Supports delegated and collaborative access, with private access scoped both by directory hierarchy and by time rather than as a flat all-or-nothing secret
Adds an asynchronous sharing layer where device-published exchange keys and share payloads let senders deposit private read keys and/or UCAN write capability for later retrieval
Has an official Rust and WebAssembly implementation built around generic block-store interfaces rather than one mandatory storage backend
Key claims:
The WNFS spec README is the clearest high-level statement of purpose: it describes WNFS as versioned, logged, programmable, strongly but flexibly secure, fully user-controlled, and able to let service providers validate writes without reading file contents while leaking minimal metadata.
The private-partition spec shows that the important control surface is not just encrypted files, but hierarchy-plus-time access. Access can be granted to a subtree from a point in time forward, while avoiding parent/sibling disclosure and avoiding retroactive access to earlier history.
The private spec’s PrivateForest and dark forest language is analytically important because it makes metadata protection a first-order design goal. The encrypted layer is intentionally flattened into HAMT-addressed ciphertext blocks so storage providers can host and validate state without learning normal file-tree structure.
The shared-private-data extension is what keeps WNFS from being just a private filesystem. It adds store-and-forward sharing for offline recipients, device-scoped exchange keys, and share payloads that can contain either read secrets or UCANs granting write access to parts of the public or private filesystem.
The Rust implementation README confirms that WNFS is designed as a substrate rather than an app: it highlights public/private subsystems, collaborative editing, IPLD serialization, WebAssembly targets, and a pluggable BlockStore abstraction instead of a single required node or chain.
WNFS belongs in the active corpus because it makes the user-data control plane unusually legible. Naming, metadata hiding, version history, share discovery, device-key publication, and executor/storage separation are all explicit rather than hidden behind a consumer storage brand.
Whitepaper: No standalone WNFS whitepaper surfaced in this pass. The strongest primary materials were the specification suite and the official Rust implementation README; see ../whitepapers/wnfs-primary-sources-2026-05-12.md.