File System (WNFS)
Working with the ODD SDK File System (WNFS)
The Web Native File System (WNFS) is a file system built on top of the InterPlanetary Linked Data model (IPLD). Each ODD user has their own WNFS, and apps store user files and data in it.
Each file system has a public tree and a private tree, much like your macOS, Windows, or Linux desktop file system. The public tree is "live" and publicly accessible on the Internet. The private tree is encrypted so that only the owner can see the contents.
All information (links, data, metadata, etc.) in the private tree is encrypted. Decryption keys are stored so that access to a given directory grants access to all of its subdirectories.
WNFS is structured and functions similarly to a Unix-style file system, with one notable exception: it's a Directed Acyclic Graph (DAG), meaning that a given child can have more than one parent (think symlinks but without the "sym").
Permissions
An ODD app assumes full access to the file system unless given a permissions
object in the configuration, then it assumes authorization to parts of the filesystem will be granted when requesting capabilities from another app.
Paths
WNFS uses directory and file paths built from path segments by path functions.
All WNFS operations expect paths created by path functions. See the path API documentation for more path utility functions.
Path Objects. The path functions create objects like { directory: ["public", "some", "directory"] }
or { file: ["public", "some", "file"] }
. We recommend you use path functions because they validate paths to make sure they are well-formed.
File System Interface
WNFS exposes a POSIX-style interface:
write
: write to a fileread
: read from a fileexists
: check if a file or directory existsls
: list a directorymkdir
: create a directorymv
: move a file or directoryrm
: remove a file or directory
Publish
The publish
function synchronizes your file system with the Fission API and IPFS. WNFS does not publish changes automatically because it is more practical to batch changes in some cases. For example, a large data set is better published once than over multiple calls to publish
.
Returns: CID
the updated root CID for the file system.
Remember to publish! If you do not call publish
after making changes, user data will not be persisted to WNFS.
API Summary
Methods
Methods for interacting with the filesystem all use absolute paths.
Paths created by path functions have a FilePath
or DirectoryPath
type. Methods with a DistinctivePath
param accept either a FilePath
or a DirectoryPath
.
The FileContent
that WNFS can store includes FileContentRaw
, Blob
, string
, number
, and boolean
. FileContentRaw
is Uint8Array
. In addition, the private file system can store Object
s.
write
Writes to a file at a given path.
Params:
path:
FilePath
requiredcontent:
FileContent
required
Returns: CID
the updated root CID for the file system
Example:
read
Reads from a file at a given path.
Params:
path:
FilePath
required
Returns: FileContent
Example:
exists
Checks if there is anything located at a given path.
Params:
path:
DistinctivePath
required
Returns: boolean
Example:
get
Retrieves the node at the given path, either a File
or Tree
object
Params:
path:
DistinctivePath
required
Returns: Tree | File | null
Example:
ls
Returns a list of links at a given directory path
Params:
path:
DirectoryPath
required
Returns: { [name: string]: Link }
Object with the file name as the key and its Link
as the value.
Example:
mkdir
Creates a directory at the given path
Params:
path:
DirectoryPath
required
Returns: CID
the updated root CID for the file system
Example:
mv
Move a directory or file from one path to another.
Params:
from:
DistinctivePath
requiredto:
DistinctivePath
required
Returns: CID
the updated root CID for the file system
Example:
rm
Removes a file or directory at a given path.
Params:
path:
DistinctivePath
required
Returns: CID
the updated root CID for the file system
Example:
Versioning
Each file and directory has a history
property, which you can use to get an earlier version of that item. We use the delta
variable as the order index, primarily because the timestamps can be slightly out of sequence due to device inconsistencies.
Requesting many versions with file.history.list
can be slow. The acceptable delay will depend on your application.
File system utilities
An ODD program
includes a set of utility functions for working with the file system:
addPublicExchangeKey. Stores the public part of the exchange key in the DID format in the
/public/.well-known/exchange/DID_GOES_HERE/
directory of the user's file system.addSampleData. Add sample directories and a file to the file system for quick experimentation.
hasPublicExchangeKey. Checks if the public exchange key was added in the well-known location.
load. Loads the user's file system.
recover. Recovers a file system.
See Sharing Private Data for more information on addPublicExchangeKey
and hasPublicExchangeKey
.
Loading the file system
The file system is loaded by the ODD SDK at program initialization, but there are times when you may want to delay loading it. For example, you may want to load the file system in a Worker.
You can load a file system with load
function:
Recovering a file system
File system recovery is a utility for recovering a user's data when their account cannot be fully recovered. Your app must store a user's username
and file system encryption key in a recovery kit or secure storage such as a password manager or iCloud.
A recovery kit might be a text file that looks like:
The username
is available on program.session
. You can access the encryption key with the following:
The recover
function works by assigning the file system to a new user:
The recover
function will automatically register newUsername.
You must check that the new username is valid and available before calling recover
with it.
File system event listeners
An ODD program
emits events on local changes to the file system and when the file system is published.
File system behavior
Conflict Resolution
A user may access their file system from more than one device. When multiple devices write to the same resource, the last write wins. We will improve this approach in a future release of the ODD SDK and WNFS. See https://github.com/wnfs-wg/roadmap/issues/12 for more details.
Offline and slow network connections
When a device goes offline or has a slow connection, it will continue to persist changes locally in the browser. The ODD SDK syncs changes when the file system is loaded or when it detects a browser has come online.
Sync
A device may not be aware of changes that another device has made. To pull changes, reload the file system. We plan to add an interface to subscribe to file system changes across devices: https://github.com/oddsdk/ts-odd/issues/414.
Last updated