4 ms·

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 w

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?

simias 9y ago
I'm also surprised that there's no Fuse interface, it's the first thing I expected while reading the title. For single process crypto storage I'd sooner use a crypto shim for SQLite, I don't know if there's any good one available out there (besides the one sold by the SQLite devs).
- chrisballinger 9y ago
  You can use SQLCipher [1] with libsqlfs [2], which has a FUSE interface. 1. https://github.com/sqlcipher/sqlcipher https://github.com/sqlcipher/sqlcipher 2. https://github.com/guardianproject/libsqlfs https://github.com/guardianproject/libsqlfs
- burmecia 9y ago
  Don't be surprised as this no Fuse support is by design. :-)
burmecia 9y ago
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.
- simias 9y ago
  I don't really understand what you mean, for me what you're saying is a contradiction: >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. I agree, but then you don't really do that, do you? Merely mimicking the Rust fs API is not enough to call your project a "filesystem" in my opinion. It's actually probably the least of my concerns when it comes to using a filesystem. On the other hand not being able to use the familiar "cd", "grep", "cp", "mv" and "cat" the contents of this so-called filesystem means that it's really not that familiar at all. I'm not sure I see the point of the "minimal attack surface", you can create private fuse mounts that can't be accessed by other UIDs. And if you're worried about same-UID compromised programs snooping around then it's game over anyway. That smells a bit like FUD to me.
  - burmecia 9y ago
    IMO, "cd", "grep", "cp" and etc. are provided by shell and os, not by file system. They are just human interface to help you interact with the underlying file system. Can you call "cd" on an ext4 file system directly? No. The shell will invoke "cd" or similar process and that process will do the system call to kernel, and then kernel will call the ext4 kernel module through VFS. https://www.kernel.org/doc/Documentation/filesystems/vfs.txt https://www.kernel.org/doc/Documentation/filesystems/vfs.txt For Zbox, it is just like a kernel module but runs inside application memory space. To interact with it, you have to use a set of 'standard' API, in kernel that is VFS, in Zbox that is Rust's fs API (not exact same, but similar).

simias 9y ago

I'm also surprised that there's no Fuse interface, it's the first thing I expected while reading the title. For single process crypto storage I'd sooner use a crypto shim for SQLite, I don't know if there's any good one available out there (besides the one sold by the SQLite devs).

chrisballinger 9y ago
You can use SQLCipher [1] with libsqlfs [2], which has a FUSE interface. 1. https://github.com/sqlcipher/sqlcipher https://github.com/sqlcipher/sqlcipher 2. https://github.com/guardianproject/libsqlfs https://github.com/guardianproject/libsqlfs
burmecia 9y ago
Don't be surprised as this no Fuse support is by design. :-)

burmecia 9y ago

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.

simias 9y ago
I don't really understand what you mean, for me what you're saying is a contradiction: >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. I agree, but then you don't really do that, do you? Merely mimicking the Rust fs API is not enough to call your project a "filesystem" in my opinion. It's actually probably the least of my concerns when it comes to using a filesystem. On the other hand not being able to use the familiar "cd", "grep", "cp", "mv" and "cat" the contents of this so-called filesystem means that it's really not that familiar at all. I'm not sure I see the point of the "minimal attack surface", you can create private fuse mounts that can't be accessed by other UIDs. And if you're worried about same-UID compromised programs snooping around then it's game over anyway. That smells a bit like FUD to me.
- burmecia 9y ago
  IMO, "cd", "grep", "cp" and etc. are provided by shell and os, not by file system. They are just human interface to help you interact with the underlying file system. Can you call "cd" on an ext4 file system directly? No. The shell will invoke "cd" or similar process and that process will do the system call to kernel, and then kernel will call the ext4 kernel module through VFS. https://www.kernel.org/doc/Documentation/filesystems/vfs.txt https://www.kernel.org/doc/Documentation/filesystems/vfs.txt For Zbox, it is just like a kernel module but runs inside application memory space. To interact with it, you have to use a set of 'standard' API, in kernel that is VFS, in Zbox that is Rust's fs API (not exact same, but similar).