Encryption, Filetree, Typos

docs/ecosystem/grants-funding.md

@@ -16,7 +16,7 @@ For grants, applications will be reviewed based on the following criteria.
 
 | <100k         | 100k - 200k   | 200k+ |
 | ------------- |:-------------| :-----|
-| one round of review.| Two rounds of review. | Interviews, formal committee review, pitch & memo.
+| One round of review.| Two rounds of review. | Interviews, formal committee review, full pitch.
 
 
 For seed funding, the Jackal Foundation or Investment Network may support an ecosystem project with equity or token investments. For innovative founders that bring strategic value and adoption to the Jackal Ecosystem, please reach out directly to our team directly. 

docs/protocol/encryption.md

@@ -0,0 +1,18 @@
+---
+sidebar_position: 2
+---
+# Encryption
+Jackal has two main features that rely on encryption techniques to keep user data private and secure. The two main models are file encryption and file-entry encryption. These reside in different locations within the protocol. The files themselves are stored on Storage Providers, which require files to be encrypted before they are transferred to those machines. The file entries are data structures living directly on-chain in the File Tree blockchain module, again needing to be encrypted on the client's device before being sent to the blockchain. The file encryption model is simply performed by taking the file as raw bytes and randomly generating a key in the user's client. This key is called a Symmetric Key. We then pass both the key and the file through AES256 encryption, which results in an encrypted file that can safely be sent to the Storage-Providers.
+
+
+__TODO: encrypting file image__
+
+What is done with this key is equally important as the encryption performed on the file; if the key were made public, all encryption on the file itself would be naught. Therefore, we need to store this key somewhere safe and immutable. This safe place is the Jackal Chain, specifically the File Tree Module. The key is stored in the encrypted form alongside the file's location to make mapping each key to its respective file easy. To get this key into its encrypted form, we use an Integrated Encryption Scheme based on AES and the Elliptic Curve used to generate Bech32 Addresses [Reference]. To do this, the protocol takes a user's public key and encrypts the private key with it.
+
+__TODO: encrypting file entry image__
+
+After this, the protocol ends up with an encrypted key that only the user whose public key was used can decrypt. When looking to decrypt a file, the process is reversed and instead uses the user's private key to decrypt the symmetric key. Following the retrieval of the symmetric key, we can decrypt the file stored on the Storage-Providers, leaving us with the originaly uploaded file.
+
+__TODO: encrypting decrypting file image__
+
+When sharing files, we can semi-repeat this process by first decrypting the key from the chain. Then we can grab the public key of an external user from the chain itself and encrypt the files with that key instead of our own. Finally, we append the newly encrypted symmetric key to the file entry giving that user access to the key.

docs/protocol/modules/filetree.md

@@ -3,8 +3,26 @@ sidebar_position: 8
 ---
 # filetree Module
 
+## Overview
+The File Tree module is responsible for keeping record of a user's files and organizing them in a way that is accessible. When a user uploads a file using the Storage module, the file is only accessible from the File ID (FID) which makes the process clunky and obtuse to remember every file uploaded to Jackal. Furthermore, 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. The solution to this is a tree structure storing 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 their respective key.
 
-## filetree
-__TODO: Description__
 
-__TODO: Visual Aid__
+
+__TODO: Folder Image__
+
+## 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, system believes it is storing files that act as metadata stores, which then updates 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 files entries on-chain is a hurdle being that 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. 
+
+__TODO: File Entry Image__
+
+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 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 for 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.
+
+__TODO: File Tree Actions Images__