We recently shared an introduction to Webnative File System that provides a comprehensive overview of it's decentralized architecture. Now let's take a closer look at a few more concepts from Co-Founder and CTO Brooklyn Zelenka's Strange Loop presentation.

Image of a cat with glasses and holding a file folder with papers standing next to a filing cabinet. This is the WNFS mascot.
Winnie, the WNFS Mascot

Hash Linked Files

Webnative file system, or WNFS, uses content addressing as the backbone of its file structure. Content addressing allows us to search for files using hashes - hard links that point to a specific version of the file.

When you change one bit of a file, a new hash is generated for that new revision of that file. You also update everything above it in the hash-linked layout. So for the example above, if we made a change to the caricature.jpg file, it would create a revision of that file, as well as the Avatars folder and the Photos directory. The Vacation folder and beach file however would remain the same and the new Photos directory would point to the Vacation folder and beach file.

This feature, called persistent versioning, is key because it allows users to sync their files across devices and collaborate with others (both on and offline).

Cryptrees: One Key per Entrypoint

WNFS uses a collection of cryptrees (called a dark forest) to ensure that users have complete control over who has access to their private files. This is done by giving every file and every folder a unique key. You can only decrypt what your key is able to unlock, and you can continue to unlock files as far as your access takes you. It's also important to note that cryptrees can be any data structure, like a database for example. (Which, incidently, is something we're working on!).

Privacy-Preserving Paths

Webnative File System uses cryptographic accumulators and quasi-commutative hashes to obscure the file paths for private WNFS files so that users can't identify what files you are storing based on context. Cryptographic Accumulators were first proposed by Josh Benaloh and Michael de Mare in 1993 and refer to a "one-way" membership hash function. It works a little like blockchains, and some blockchains use them, but the difference is when you look backwards in the chain, you are only able to verify the content and not the individual contributors to the chain. It scrambles users' "file paths" so much that even the path creator may only know part of the path.  

This is useful for a number of reasons. For example, if you have a file named bali-trip.xlsx that you want to share with a travel agent, you may not necessarily want them to see that the bali-trip file is nested within a folder labeled My Finances. They may assume that your tax returns are in that folder as well as other sensitive paperwork. The wrong person looking to steal information may try to break into those files first because you've clued them into what's located there.

In WNFS, you can share your bali-trip.xlsx file and scramble the hard links so anyone viewing your file can't identify its path. If you decide that you want that person to have more access, you can give them the key necessary to decrypt it and WNFS reconstructs its file structure for the user.

Another analogy is it's like having a LEGO brick castle that is taken apart, so all you have are the individual pieces. But then someone hands you the instruction manual and you're able to put it back together. That's what the cryptographic accumulator does as long as you can prove you have access.

This access comes in the form of a UCAN, which acts like a verifiable certificate stating that the user can be granted access to those files and they should be given a key.

Temporal Access Control

Earlier we mentioned cryptrees and how they work as the structure of the private file system. Up until now, cryptrees have had no ability to go back in time to previous revisions. Once you delete a file or a folder, it's gone forever.

But keeping past versions of files and folders is actually really handy. How many times have you deleted an old file and realized there was some information in there you actually wished you retained?

In the past we deleted them because storage was more expensive and we wanted to prevent old information from being accessed. But now storage is cheap, and with content addressing you can pick exactly which revisions of files you want to share with people because each revision has a unique hash.

With all this in mind, we have introduced a new dimension to cryptrees. Now, not only do cryptrees work in space (file hierarchy), but they work in time too (file history).

The time dimension also allows concurrent writing to happen, so users can access and edit files offline and sync them back up when they are online again.


In a future post we'll share Brooklyn's Strange Loop presentation on skip ratchets,  which makes progressive fast-forwarding in a temporal data structure less time-consuming.

In the meantime, do check out the full Webnative File System presentation here:

Brooklyn's presentation slides are also available.