- client sends file name + file size to manager
- manager sends OTK to chosen storage node, and approx file size (approx because encryption <3)
- manager sends OTK and "random" file name (asdasdl.a.png) to client
- client gets hash of original file, then encrypts file with random file name and posts encrypted file with obfuscated file name
- after statuscode 200 from storage node to client, client sends manager hash (also stores it for personal verification)
- storage node sends "filename" to manager
- manager adds "random file name" | filedata to db(/dev/null), UNLESS hash is in the hashes table, if in the hashes table the filedata from the original hash is copied to "random file name" | filedata (this is where original-name) is important, because you need the storagenode filename & the "decryption" filename
- if duped, send a delete request to storagenode of "file"
- etc etc etc
- OTK also serves as transaction ID
- OTK only valid for one file upload
- client sends file name request to manager
- manager checks file name existence, sends server url and sends otk to server and client (client also recieves "actual file name" to decrypt & hash)
- if storage node is down cry
- storage node streams to client
- client decrypts with actual file name, also checks hash
- goal, 2 copies of file for each file?
database structure:
snode_id | url, allows_dedup, allows_rebalance, size_left, id file-name | snode_id, original_file_name, file_hash
//todo OTK/transaction temp thing
storage node databse structure:
mnode_id | url, size_left (calculated on startup), file-name | owner_node_id
``
- potential multiple manager nodes can sync their files so you can access files uploaded from every manager
- multiple files requiring one OTK