The File Tree Module

The Jackal Filetree module organizes and manages user files securely and is user-friendly. When a user uploads a file using the Storage module, the file is only accessible from the File ID (FID), which can be challenging to remember for every file uploaded to Jackal.

Additionally, every single upload would be required to be public, or the user would need to keep track of every symmetric key used to encrypt the files and manually map them to the FIDs.

To address this issue, the File Tree module implements a tree structure that stores each file as an entry in the tree. Organizing this structure is also trivial, as we can assign children to pseudo files that we call folders.

Finally, the protocol maps every file to its respective key to keep track of encryption keys, emphasizing the security and privacy posture that the File Tree module enables.

Folder Abstraction

Of course, these are all abstractions of what's actually under the hood. The File Tree module doesn't handle any folder logic; the system believes it stores files that act as metadata stores, which then update to reflect changes in folders.

This gives the user experience the feeling that folders and files are separate entities in the tree, but in reality, they are identical.

File Entry Structure

Storing file entries on-chain is a challenge since the chain itself is public. This requires using client-side encryption before uploading data to the chain itself.

The main component of a file is its location (Address), which allows users to query the rest of the data in the file.

You can think of the location as a key in a traditional key-value store or a path in bucket-based storage. The address is hashed using SHA256 to ensure it is impossible to retrieve the plain-text representation of the file name while still being able to query the file using its given name.

The second most important data point in a file is its content. This field is extremely versatile, as it can store any string. Traditionally, it is used to store a JSON list of FIDs to point to a file on the Storage Module; however, the protocol can also theoretically use it to store short bits of text like encrypted passwords for a private password manager.

The owner tag is a hashed version of the owner, hiding what address owns each file. This field can be changed to reflect the transferral of ownership. When making changes to the file, such as deletion, movement, or adding/removing viewers/editors, the owner field is consulted to determine permissions. The same applies to edit access; editors can update the contents but nothing else.

Encrypted Viewing Access

Users need access to the symmetric keys used to encrypt the files in order to view them. To do this, the protocol has a map of hashed addresses, with each user's respective version of the symmetric key encrypted with that address's corresponding public key.

The protocol can then store that map in the file entry as an encryption key discovery layer. The addresses in this viewing list can only access files and decrypt the data in their client; they have no privileges over modifying the file entry in any way.

This approach ensures that the File Tree module maintains a strong security and privacy posture for user data.