53 lines
3.4 KiB
Markdown
53 lines
3.4 KiB
Markdown
---
|
|
sidebar_position: 8
|
|
---
|
|
|
|
# Filetree Module
|
|
|
|
## Overview
|
|
|
|
The Jackal Filetree module is responsible for organizing and managing user files in a secure and user-friendly way. 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 to store 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,
|
|
to keep track of encryption keys, the protocol maps every file to its respective key, emphasizing the security and
|
|
privacy posture that the File Tree module enables.
|
|
|
|
|
|
|
|
## Folder Abstraction
|
|
|
|
These, of course, are all abstractions of what's actually under the hood. The File Tree module doesn't actually handle
|
|
any of the folder logic; the system believes it is storing 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 the use of client-side
|
|
encryption before uploading data to the chain itself. The main component of a file is location (Address), allowing users
|
|
to query the rest of the data from 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 the content of the file. This field is extremely versatile as it can
|
|
store any string. Traditionally this 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
|
|
|
|
For users to view files, they need access to the symmetric keys used to encrypt the files. 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 to act as an encryption key discovery
|
|
layer. The addresses in this viewing list are only able to access files and decrypt the data in their client; they have
|
|
no privileges over the modification of the file entry in any way. This approach ensures that the File Tree module
|
|
maintains a strong security and privacy posture for user data.
|