burmecia

Thanks for your praise. To answer your questions:

- Where exactly does "zero-knowledge" play a role here? Does this provide steganography? Or, what is meant?

As I said in https://github.com/zboxfs/zbox/issues/4, this term was originally for marketing purpose. It means no data or metadata can be leaked to underlying storage, so for an outsider there no knowledge about its content. But it turns out many people think it is misleading to zero knowledge proof in cryptography, so I have already changed it "zero-details".

- Why do they use libsodium (excellent choice, but C) instead of a native Rust crypto library?

libsodium is a great library, it is fast, sophisticated, mature and has some advanced crypto features I like, such as Argon2 hash and AES nonce extension. I know there are some Rust crypto libraries are great, but overall it is still young and need improvement.

- Does this only work with Rust applications?

Yes, for now only Rust. But I am considering add FFI interface so it can be used by other languages.

Don't be surprised as this no Fuse support is by design. :-)

Zbox author here. Woo, I didn't even prepared for a HN debut. :-) Anyway thanks for your comments.

One of the major goals of this project is to keep app files private, which means exposure surface must be as minimal as possible. To this end, it intentionally does not support mount/FUSE or other mechanisms which can 'share' access across processes. Zbox doesn't allow multiple processes access, even those processes are under same user account.

For your question why not make it an embeddable key-value store. I think, IMHO, file store is more generic. We have VERY long history using file system, it is the base of every OS, it has solid API, every language provide similar access interface, everybody familiar with how to talk with file system. For Zbox it also provides similar API to Rust's file system API, that will make most developers much easier to adopt it.