added images to docs

docs/p-o-p.md

@@ -11,15 +11,15 @@ If a Storage Provider successfully posts a Merkle Proof within the challenge win
 ## Building the Trees
 Merkle Trees are a core component of the JPOP mechanism, thus, it is important to outline how these trees are used to create efficient and trustworthy proofs. When saving a file for the first time, providers split each file into many 1kb chunks. Providers must also hash the entire file to create a folder to house every chunk, this is displayed by  the following diagram.
 
-__TODO__: Tree Image
+![File Tree](/img/jkl_paper/tree1.png)
 
 These chunks are used as leaves on the Merkle Tree defining each storage contract. Immediately after saving a file to disk, the storage provider builds a tree using each chunk. To create this tree, each chunk is hashed into a respective Hashed Chunk. These chunks are then recursively paired together and hashed until a single root node is created. This is called the Merkle Root, the only piece of data relative to a file that is saved directly on the blockchain itself.
 
-__TODO__: Root Image
+![Merkle Roots](/img/jkl_paper/tree2.png)
 
 In the diagram above, displays how each file is hashed together to create a single root node.
 
 ## Proving Data Availability
 These nodes are essential as they only require the nodes below them to prove they are part of the tree. This means that we can create a proof claiming a single chunk belongs to the file using the Merkle Root saved on chain. In the following diagram we can see that only the blue nodes are required to build a successful proof. The green nodes represent information that we can generate given the blue nodes. Finally, we can compare the root generated from the proof to the root saved on the chain and determine if the chunk does actually belong to the contract we are proving. This results in small message sizes due to not needing to send the entire file every proof.
 
-__TODO__: Root Image with color
+![Merkle Roots Graphed](/img/jkl_paper/tree3.png)

docs/protocol/encryption.md

@@ -5,14 +5,14 @@ sidebar_position: 2
 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__
+![Protocol Overview](/img/jkl_paper/enc1.png)
 
 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__
+![Protocol Overview](/img/jkl_paper/enc2.png)
 
 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__
+![Protocol Overview](/img/jkl_paper/enc3.png)
 
 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/dsig.md

@@ -7,6 +7,4 @@ sidebar_position: 7
 
 The dsig module is a digital signature service that allows users to collect signatures from multiple users who are registered on the Jackal Blockchain. Users can create 'forms' associated with a unique file stored on Jackal and can add signees (users) to collect their signatures. The signees have the following options to respond: Approve, Deny, Abstain, and No Response (Default). The form can execute a custom function after all users have voted to Approve the form.
 
-__dsig images__
-
 

docs/protocol/modules/filetree.md

@@ -6,10 +6,9 @@ sidebar_position: 8
 ## 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.
 
+![Protocol Overview](/img/jkl_paper/filetree1.png)
 
 
-__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.
 
@@ -17,7 +16,7 @@ These, of course, are all abstractions of what’s actually under the hood. The
 
 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__
+![Protocol Overview](/img/jkl_paper/filetree2.png)
 
 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. 
 
@@ -25,4 +24,3 @@ The second most important data point in a file is the content of the file, this
 
 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__

docs/protocol/modules/jklmint.md

@@ -6,5 +6,4 @@ sidebar_position: 2
 ## jklmint
 The Jackal Mint module is a replacement for the cosmos-sdk module: [Mint](https://github.com/cosmos/cosmos-sdk/blob/main/x/mint/spec/README.md). The key differences between this and the pre-existing minting module are that jklmint does not adjust inflation based on rate of bonded tokens. At genesis, the jklmint module prints 10 JKL per block and distribute it to both the storage module and the default distribution module.
 
-__mint image__
 

docs/protocol/modules/lp.md

@@ -9,4 +9,3 @@ sidebar_position: 3
 ## lp
 The lp module allows for a native automated market maker (AMM) liquidity pools (LP) to be built directly into the Jackal Blockchain. This allows for local prices for payment mechanisms without the need for oracles, along with the ability to swap tokens directly from the Jackal dashboard or the Jackal Swap service. 
 
-__lp images__

docs/protocol/modules/module-overview.md

@@ -4,5 +4,5 @@ sidebar_position: 1
 # Module Overview
 
 
-__JACKAL PROTOCOL IMAGE__
+![Protocol Overview](/img/jkl_paper/protocol.png)
 

docs/protocol/modules/rns.md

@@ -6,5 +6,3 @@ sidebar_position: 4
 ## rns
 The rns module is a name service that allows users to manage human-readable names when interacting with the Jackal Blockchain. Users can register names, list names for sale, buy names on the marketplace, and place/accept bids from other users on their names.
 
-__rns images__
-

docs/protocol/modules/storage.md

@@ -8,7 +8,5 @@ Jackal Storage functions by a Proof-of-Storage algorithm we call Proof-of-Persis
 
 If a Storage Provider successfully posts a Merkle Proof within the challenge window for the contract and the data is verified by the Validators to be valid Merkle Proofs for the challenge index, the Storage Provider is paid out. Storage Provider rewards are proportional to the file size the contract is associated with relative to every other active contract on the network. If a Storage Provider fails to provide a valid proof within the allotted timeframe, the contract is struck with a missed proof. After (X) missed proofs, the contract is burned, and the user is alerted the next time they query the contract. For every contract burned through missing proofs, the Storage Provider is struck with a penalty that remains on their record for a period of time adjustable through governance.
 
-__Storage Images__
-
 ### Interaction Outline
 A user first sends a file to an available Storage Provider. A list of Storage Providers can be found on the blockchain, and providers can deny any incoming request if they wish not to store new files. The Storage Provider, after receiving the entire file, keeps that file in memory and posts a contract to the blockchain. If the contract is not signed by the sender in X blocks (configurable by the Storage Provider), then the file is removed from memory, and the contract is burned. However, if the contract is signed by the user within the given blocks, the file is committed to the Storage Provider's hard storage, and the challenge windows start being created for the now active contract.

docs/protocol/storage-providers.md

@@ -4,8 +4,6 @@ sidebar_position: 4
 # Storage Providers
 A Jackal Storage Provider is a dedicated web server optimized for data storage that accepts incoming files from users and creates contracts for the users to approve. These contracts last until the user either cancel them or the provider itself goes offline.
 
-__Storage Provider Images__
-
 __TODO: Storage Provider Setup__
 
 

pkg/sumdb/sum.golang.org/latest

@@ -1,5 +0,0 @@
-go.sum database tree
-11348477
-MxmzLhB4z5nC5saZJNrh8aeJLMxFvUDbEi/O3aU3a0I=
-
-— sum.golang.org Az3grqgr0okRWpq87K30ujJMCPFbwC6t+nH+te5cnyI76+gUy51mIT1lSmDksK7syvESZPhVipFbjP6ql7k6bxvVeQU=