v0.1 Beta 3 (RC)

Minor improvements to get ready for submission.

v0.1 Beta 2 (RC)

Features

• Adds L1 cache
• API keys for clients
• Limit Macaroons to delegates

v0.1 Beta 1 (RC)

Documentation

• Developer ocamldoc on each module in stack

v0.1 Beta 0

Features

• All C2P and P2P communication is now over HTTPS
• All files in data silos are encrypted
• P2P messages are signed with the RSA private key of the sender
• C2P messages are authenticated against the secret clients share with their peer
• Best attempt to remotely invalidate cache entries with relogging if fails

v0.1 Alpha 5

Features

• Remote writes
• Remote deletes
• Optimised verification of attached capabilities

Internal

• Adds Api.mli
• Refactors class type for server
• Removes redundant code
• Adds more tests for Auth.CS

v0.1 Alpha 4

Features

• Recursively read down from directories as well as absolutely to files
• Moves read logging to log all files in read result, not in read request

v0.1 Alpha 3

Features

• Adds terminate predicate parameter in File_tree.insert to terminate early on insert if terminate on a node payload is true anywhere along path

v0.1 Alpha 2

Features

• Trims Peer_access_log entries after invalidating

Internal

• Abstracts a capability service rather than raw File_tree in Auth.CS
• Removes all compiler warnings caused by the osilo code, the ones left seem to be linking problems with external libraries.

v0.1 Alpha 1

Features

• Greedily minimises set of capabilities sent with a read request

v0.1 Alpha 0

Version 0.1 at alpha. Merging in PR #59 signified hitting project success criteria, light testing suggests this works at low scale and loads.

Features

• Distinct Client -> Server (encrypted with shared private key) and Peer -> Peer (encrypted using negotiated shared private key) APIs
• Clients can retrieve data, write data and delete data from their own servers/peers
• Clients can ask their servers to get data from other peers
• Clients can ask their servers to mint and send capabilities to other servers
• Clients can ask their servers to tell all peers that have retrieved their data previously, on a fine-grained basis per file or per directory to remove that data from their cache
• Peers can negotiate and cache private keys with other peers, if a stale key is used they renegotiate to update and retry
• Peers can get data from other peers if the other peers have given them appropriate capabilities previously
• Peers can tell other peers to invalidate their data in that peer's cache
• Servers/peers can be pinged to check for liveness