I will be a bit harsh with the project since I understand it aims to be a technology to be used in production and not just a pet project... (not "Show HN" tag was present.)

I only see here yet another key value store with an application programming interfaces that resembles the typical filesystem operations, but it is only accessible within a programming framework.

I know it is not finished but the flaws I see at the moment are completely fundamental: it aims to be general purpose, not unix compliant, not mountable, not language or truly operating system agnostic and in conclusion does not permit leverage existing filesystem tools such as mount/find/grep/sshfs etc... not to speak about support for multiple processes, users, time validations...

I wish you all the luck in the world as pet project (really! especially since filesystems are quite hard to get mature and stable) but I hope it never succeeds as a serious alternative to filesystems, because that could be worse than mongodb to rdbms.

Now trying to be constructive: there is value in the concept of runtime embeddable file systems. Why don't reframe the project as a key-value store which is embeddable within applications and mountable? (for example via fuse so you can even mount it mac/linux/others). Even if it is mountable only as RO that could bring several advantages over existing key-value-stores and advanced filesystems which are not embeddable.

Again, impressive work, good luck.

EDIT: the way you store data is also a great discussion topic... who is interested in so many possible ways to store the information anyway? that mostly depends on the requirements of the consuming application... for example if you target users which want to have a file-system-alike embedded runtime, why they would like to use this project if they have access to advanced unix compliant filesystems which support encryption and RAID and advanced tools out of the box?