many docs

docs/encryption.md

@@ -0,0 +1,29 @@
+# Encryption
+
+If a password is set, the files are encrypted before being sent to the cloud.
+
+The encryption algorithm is delibrately designed to be aligned with openssl format.
+
+1. The encryption algorithm is implemented using web-crypto.
+2. The file content is encrypted using openssl format. Assuming a file named `sometext.txt`, a password `somepassword`, then the encryption is equivalent to the following command:
+
+   ```bash
+   # file content encryption (ignoring file path encryption)
+   openssl enc -p -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:somepassword -in ./sometext.txt -out ./sometext.txt.enc
+
+   # file content decryption (ignoring file path decryption)
+   openssl enc -d -p -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:somepassword -in ./sometext.txt.enc -out ./sometext.txt
+   ```
+
+3. The file/directory path strings, are encrypted using openssl in binary mode and then `base32` is applied.
+   Assuming the file path is `a-folder-文件夹/a-file-文件.md`, then the following commands are equivilent:
+
+   ```bash
+   # pure string encryption then base32
+   echo -n 'a-folder-文件夹/a-file-文件.md' | openssl enc -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:mylongpassword | base32 -w 0
+
+   # pure string base32 then decryption
+   echo -n 'KNQWY5DFMRPV7UHRWVYFSHE2XVVVZCFN65SR7ETEKO5L6EYGXCVEPT4A2LVTW4W2ZHXWF3K22SVA562CCZ6SALARXJY6AAXXHLK5UOA=' | base32 -d -w 00 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:mylongpassword
+   ```
+
+4. The directory is considered as special "0-byte" object on remote s3. So this meta infomation may be easily guessed if some third party can access the remote bucket.

docs/minimal_intrusive_design.md

@@ -0,0 +1,36 @@
+# Minimal Intrusive Design
+
+The plugin tries to avoid saving additional meta data remotely.
+
+## Benefits
+
+Then the plugin doesn't make any assumptions about information on the remote endpoint.
+
+For example, it's possbile for a uses to manually upload a file to s3, and next time the plugin can download that file to the local device.
+
+And it's also possible to combine another "sync-to-s3" solution (like, another software) on desktops, and this plugin on mobile devices, together.
+
+## Flaws
+
+The main issue comes from deletions (and renamings which is actually interpreted as "deletion-then-creation").
+
+Consider this:
+
+1. The user create and sync a file to the cloud on the 1st device.
+2. Then download this file to the 2nd device.
+3. And then delete this file on the 1st device.
+4. And sync on the 1st device. The file on the cloud is also deleted.
+5. And sync on the 2nd device. **The 2nd device would upload the file again to the cloud.**
+
+In step 4, the file is marked "deleted" on the 1st device, and the 1st device send the command "delete this file on the cloud" to the cloud sevice (e.g. s3). Then the file on the cloud is also deleted. So far so good.
+
+But, in step 5, because no meta data are saved on the cloud, the 2nd device doesn't know that the file are deleted. Instead, it thinks "the file was not synced to the cloud last time, so it's uploaded this time". So an unintentional upload occurs.
+
+Currently no way to fix this if no meta data are saved remotely. The only workarounds are:
+
+1. Delete the file on the 1st device, **before** syncing it to the cloud. Then the file never show up on the cloud or on the 2nd device.
+2. Or, manually delete the file on 2nd device **before** step 5 in above situation.
+
+## Future
+
+This design may be changed in the feature, considering the flaws described above.