decisions added, missing login (any maybe others that come to mind)

delivery3/decisions.adoc

@@ -1,3 +1,57 @@
 == Decisions
+In this topic, it'll be presnted and discussed the decisions made by the authors of the project thorough its development. These can range from choices taken to be used for encryption to the implementation of the API itself.
+
+
+=== Usage of the Diffie-Hellman Key Exchange
+The Diffie-Hellman key exchange is used in this project to securely create and mantain a key where both ends (client and server) know that key, but never exchange it. Diffie-Hellman is great for this, since by exchanging the parameters used to generate the key, and each other's public key, both can end up with the same key, without ever needing to exchange it on a public channel.
+
+The key generation (public and private) is done using the parameters agreed on both ends (using the `dh` package from `cryptography`).
+
+
+=== Symmetric Encryption
+The symmetric encryption used in this project is AES-CFB. This is a symmetric encryption algorithm that is widely used and considered secure. This cipher was chosen due to the FeedBack functionality, that avoids the same plaintext to be encrypted to the same ciphertext, which is a vulnerability present in the ECB mode.
+
+This type of encryption is used to encrypt anonymous requests and files. Both use a Initialization Vector(IV) of 16 bytes, with it being randomly generated.
+
+
+=== File Handling
+As mentioned before, the files are encrypted symmetrically. The key used to decrypt them is within its metadata, which can only be accessed with the required permissions. The encryption and decryption is done by blocks (or chunks) of stem:[2^11] bytes.
+
+
+=== Session-Related Content
+By default, all keys, files and session files are stored under `~/.sio` on the client side. In order to clear all files generated by the API, please run `rm -r ~/.sio/`
+
+
+=== Hashing
+For the hashing, it was used the SHA256 hashing mechanism, since it produces a 256 byte value. This is used to check the file integrity when going from Client → Server and vice-versa.
+
+
+=== Database
+The authors of this project have chosen to use a database to store all server-side content
+
+The database used in this project is SQLite3. This was chosen due to the authors' familiarity with it, its simplicity and the fact that it is a single file, which makes it easier to manage and distribute. When needed, it can be reset using a endpoint mentioned in the Features chapter.
+
+
+=== Modularized Server
+The server is modularized in order to make it easier to maintain and expand. Each service has its own file and class, which makes it easier to understand and maintain. This also makes it easier to add new services to the server, as they can be added as new files and classes.
+
+
+=== Roles
+The roles are used to define the permissions of each user. The permissions are stored, viewed and treated as seen in other services, like Discord. This approach is as follows:
+
+[source,python]
+----
+DOC_ACL = 0b000000000001
+DOC_READ = 0b000000000010
+DOC_DELETE = 0b000000000100
+#...
+----
+
+Since it is stored in bits, validating a permission or adding it to a role is very easy, since it'll be just bit-wise operations.
+
+==== Checking a permission
+To check if a role has a permission, it can be easily done by looking at the bit corresponding to the permission, and do a simple AND operation with said bit (that bit has to be 1)
+
+==== Adding a permission
+To add a permission to a role, all that is needed is a OR operation with the current role's permissions and the bit we want to enable (permission to give). This bit has to be also 1.
 
-The methodology section will delineate the steps undertaken to achieve the project objectives, including the tools and technologies utilized, as well as any challenges encountered and the strategies employed to address them.