"A Distributed File System for Secure P2P Applications" by Brooklyn Zelenka (Strange Loop 2022)

## Overview Brooklyn Zelenka, co-founder and CTO of Fission, presents WNFS (Web Native File System)—a distributed file system for secure peer-to-peer applications built on local-first principles. The three-year project, initially dismissed as impossible, fundamentally inverts traditional server-centric architectures to let users own and control their data across multiple stores while operating offline-first.

## Motivation and Context Zelenka argues that internet infrastructure has radically changed since the 1990s: clients are now powerful (e.g., iPhone chips), bandwidth is abundant but latency is the constraint, access is distributed globally, and data privacy is increasingly regulated. Yet software architecture remains trapped in the LAMP stack paradigm of centralized servers. WNFS applies newer data structures and leverages modern client capabilities to enable users to own their data, possess one or more stores, and load data into applications as needed—mirroring how native platforms manage resources.

## Four Core Properties The system requires four properties: local-first Access Control, arbitrary metadata, mutability, and versioning. Each is essential; initial skeptics discover their necessity when exploring how to avoid them.

## Public File System: Content Addressing and Hashing The foundation uses content addressing—hashing data (e.g., SHA-256) so that identical content produces identical hashes deterministically. This differs from traditional URL-based addressing (which is location-dependent). Content addresses enable deterministic naming across distributed systems, selective replication, and clean diffs. WNFS uses IPLD (Interplanetary Linked Data) format with bytes and links. A mutable pointer (DNS TXT records) decouples addressing from data structures, permitting updates, atomic writes, and rollbacks while preserving history.

## File System Structure The layout includes: a root with owner information (public key), public content, encrypted data sections, and a sharing inbox. Public files are organized in Merkle trees: each file has a header (SDK-controlled), raw user data, and metadata; directories index files and subdirectories. Changes create new versions; shared unchanged blocks enable structural sharing. History is stored per file as a linear or branched sequence; revisions form a causal semi-lattice supporting merging. A tunable hash-based checkpoint mechanism accelerates diffs by identifying the last common ancestor across branching histories.

## Private File System: The Dark Forest Encrypted data is organized in a CHAMP (Compact Hash Array Map Prefix tree)—an optimized hash-array map trie with branching factor 16, balancing efficient diffs and shallow trees. The structure is append-only, miracleized (identical structures have identical hashes), and concurrency-friendly. All leaves appear as random bits, enabling efficient merging via set union. Every block and file has a unique key, derived randomly and unrelated to hierarchy; this prevents key rotation from affecting unrelated files. Users decrypt blocks starting from one top key, progressively discovering the tree structure—no server is queried for access proofs.

## Temporal Cryptography and Access Control Time is orthogonal to hierarchy. A key ratchet—repeatedly hashing a key to derive the next version's key—enables forward traversal in time but not backward. A skip ratchet permits efficient jumps. Granular access is provided by deriving keys: giving access to a specific file, directory, or time range creates zero-knowledge witnesses using RSA accumulators with quasi-commutativity. These accumulators hash path segments and version information together in an order-agnostic way (quasi-commutative), proving membership without revealing the path.

## Write Access and Lazy Rooting Users with partial write access create updates unrooted to the top (because the top structure is unknown to them). These are lazily attached upward when someone with higher access integrates them, performing structural sharing and backlinks. Over time, the tree is collaboratively built from leaf to root.

## Path Privacy To prevent correlation attacks (e.g., identifying legal vs. family documents), all file names and paths are encrypted. The system uses RSA accumulators to prove that a file name exists under a given parent without revealing either the hierarchy or the name itself—just opaque random bits and a witness.

## Technical Implementation Originally written in TypeScript, WNFS is being rewritten in WebAssembly and Rust to target web and native applications. The system emphasizes that "all pipes are broken"—assuming data will be compromised, so encryption-at-rest and in-transit is mandatory. The API mirrors Unix commands (ls, mkdir, rm, mv) with additions for history, versioning, and merge semantics.

## Use Cases and Future Work Deployed for web apps (Dropbox clones), tools for thought (TiddlyWiki), data science, and storage network integration. Future work includes completing the WebAssembly rewrite, building local-first encrypted collaborative data logs, expressing CRDTs as data log, improving IPFS networking (batching requests, maintaining peer connections), and deploying zero-knowledge proofs for certificate privacy. The project is driving standards via the Web Native File System working group spec.

## Key Takeaways Content addressing and Merkle trees provide security and efficient caching. Structural sharing across versions saves space while preserving history and enabling rollbacks. Temporal cryptography separates time-based access from hierarchy. Path privacy via accumulators prevents correlation attacks. Lazy rooting enables offline-first collaboration. The system scales from local use to global peer-to-peer networks while maintaining end-to-end encryption and user data ownership.