This summer Fission attended IPFS Thing, a week-long gathering in Reykjavik, Iceland for the IPFS implementors community. We gave several presentations, one of which was led by CTO Brooklyn Zelenka and Protocol Engineer Philipp Krüger introducing our Webnative File System (WNFS).
Building Web3 apps requires portable data and runtime. We also need to build Web3 apps that have feature parity with Web 2.0 (otherwise, there won't be much incentive for adoption). This includes access control, the ability to work collaboratively and concurrently, and more.
We also need to be able to search for, select, and open files within the browser itself if we want to build Web3 native apps.
The Webnative File System allows developers to do all of this through it's unique structure.
In WNFS, we utilize three virtual nodes - the Raw IPLD Node, the File Node (which contains raw data and metadata), and the Directory Node (which contains an index and metadata).
Within the Directory Node we utilize persistent versioning. Persistent versioning allows us to keep all previous versions of files. And why not? The cost of storage is getting cheaper, and having access allows us to look back at previous versions if needed (instead of them being gone forever). By default, nothing gets deleted and when you overwrite files, the previous versions remain (like Git).
Hard links (new for the web!) provide a direct reference and deduplicate files, while soft links act as pointers that are always tracking the latest version. We use a combination of hard and soft links to reference and point to previous and new versions.
Furthermore, automatic file-level reconciliation (like Git again, but without the manual merges) is also taking place, efficiently providing a persistent data structure.
So why did we design the Webnative File System this way? Why did we go to the trouble of making persistent versioning a core characteristic of the structure? The answer is we did all of this so we could make concurrent edits. This means multiple people can write at the same time, even if there is a conflict or a user is offline. It brings us to our goal of having feature parity with Web 2.0.
In the WNFS, every file in every directory gets its own key. The directory has a pointer down and a key to decrypt it. So if you can decrypt the root you can decrypt everything, but if you can only decrypt a sub-directory, you can only decrypt the files within that sub-directory.
When you create a new version of a file or folder, this action yields a new key. But now you can't read past versions with your new key - you can only read new ones. How do we solve this? Enter "fast forwarding" and a temporal data structure.
WNFS allows you to write and root as far as you can in the directory until someone else comes along with more write access than you. Then they can incorporate the new versions of your files and directories into the root in the same way that we did with persistent versioning of public files using a Seek and Attach process.
This is also made easier using a skip ratchet. Ratcheting is an approach to securing user history by iteratively generating new hashes for each version, that are linked in a chain. But if there is a long hash chain, how do you jump to the end without requiring a lot of work?
CTO Brooklyn Zelenka invented a skip ratchet to alleviate this very problem. As described in Brooklyn's paper, "A skip ratchet is capable of efficiently making large leaps in hash count while preserving backward secrecy in a passive setting." So now you can reach your newly accessible files faster, creating a better user experience.
But don't forget that we are talking about private file storage, so even though the high-level structure is the same, there are ways we work to obscure the metadata. One is through the use of bloom filters and the saturation of bloom filters so that you can't distinguish one from another.
The other way is through a Dark Forest, or a collection of cryptrees. Cryptrees ensure that users accessing files can't view any information about the file strucuture itself that they aren't authorized to see (for example, the name of the parent directory that the user doesn't have access to).
View the full presentation above and the corresponding slides for more info.
And stay tuned for a more in-depth breakdown on the Webnative File System, including details about the Sharing Inbox and Sharing Outbox options, at StrangeLoop.