News for hackers. Stuff that matters.

mycure

Re:Introducing the Infinit file system on Monday May 02, 2016 @07:59AM (#11610660)
I'm reading what I can find :) Sorry if I missed information, it was not my intention to say that IPFS was not good, just to say that the purpose was different from Infinit's.

Redundancy: https://github.com/ipfs/ipfs/issues/50. One of IPFS' core developers clearly states that there is no redundancy in IPFS. I took my information from there because it was the only one I could find with Google. It is not because one node can retrieve the data that the data is actually stored multiple times and that the storage servers coordinate to maintain consistency. From what I understand, IPFS content-hashes information (as Infinit does) but does not replicate it. As such, if a server goes down, its hosted content becomes unavailable; very much like the Web. This is not the case of Infinit (if you defined a replication factor above 1). Again, different purposes, my goal is not to say one is better; redundancy obviously has a cost.

Fault tolerance: Yes nodes can go down in IPFS but the system will not function as before as some data may be unavailable, in the worst-case scenario, permanently, should the failure be fatal. Sorry, I should have made myself clear. IPFS is fault-tolerant but does not ensure availability. Bittorrent as well. Some files may become so rare that you cannot access it anymore. Infinit ensures that all the files are available at any time. Self-certifying is another concept altogether.

Rebalancing: I don't understand exactly what you mean but if you want to provide a POSIX-compliant reliable (available/durable) file system, you need fault tolerance and rebalancing, which is to recreate missing replicas and possibly move data around as servers are added or fail. If you can't do that, then again you have the problem of potentially having unavailable pieces of information. It is fine for some systems such as the Web (not critical if you can't access some rare pages), but it is super critical for an enterprise file system in production. Again, different purposes I believe as IPFS (from what I understand, sorry if I missed something) is trying to provide a HTTP replacement: a new peer-to-peer hypermedia protocol (from http://ipfs.io).

Access control: File-level encryption is one thing but access control something else entirely: how to allow other users to read/write files and how to manage the keys. What about removing files? What about groups? Subgroups? And what about integrating into an enterprise directory (LDAP)? These compose a complete set of access control capabilities from my point of view. File-level encryption is obviously the basis for access control but is not enough. As you stated, it is planned in the protocol.

Versioning: Good to know that IPFS will be providing versioning, I didn't know that. Thanks for pointing that out.

To conclude, both projects seem to rely on some similar tech such as content hashing. IPFS seems to be going the way of a protocol for accessing data in a decentralized way (like the Web in a more modern way) but without providing redundancy, consistency and availabilities garantees. Storj is going this way for instance, providing a peer-to-peer object store (S3-like). Infinit however seems to be more focused on providing a POSIX-compliant peer-to-peer, reliable, secure and fault-tolerant file system for Ops and DevOps.

Re:Introducing the Infinit file system on Monday May 02, 2016 @06:44AM (#11610406)
Infinit's goal is not to compete against IPFS which is focusing on providing a protocol for distributing content.

IPFS does not focus on providing redundancy, fault tolerance, rebalancing or file-level functionalities such as access control, versioning etc. This is what Infinit is doing.

Two very different solutions even though they may share some technical similarities.

Feel free to ask more precise questions about the architecture but basically it goes like that.

Upon registration, a cryptographic key pair (RSA) is generated on the user's computer so Infinit does not have access to the user's private key.

Infinit keeps in its database the name, email and public key of the user. This information is used to identify someone and make it easy to find your friends, colleagues, clients etc. on the product.

When one wants to transfer files, he/she selects a contact and clicks 'Send'. From that point, Infinit identifies the recipient, connects the sender's and recipient's devices; challenges their identities to make sure it matches and finally transfers the data directly.

In this configuration, the data goes straight from the sender's to the recipient's computer, bypassing the cloud altogether.

Infinit can also be used, as you mentioned, to send to yourself i.e to another of your devices. When you do that, a notification pops up on all of your other devices. The device on which you accept the transfer will receive the files.

Re:Comparison of File Transfer Application Speed on Monday November 18, 2013 @10:46AM (#6754810)
Sorry, I replied above. Here is my response:

"The files are encrypted with RSA using the recipient's public key. In other words, Infinit never has access to the transferred data.

We compare the file transfer feature (not synchronization) which is, with Dropbox, the right click -> get a link. The LAN sync only applies to the synchronized folders which is another use case."

Re:Comparison of File Transfer Application Speed on Monday November 18, 2013 @10:40AM (#6754777)
The files are encrypted with RSA using the recipient's public key. In other words, Infinit never has access to the transferred data.

We compare the file transfer feature (not synchronization) which is, with Dropbox, the right click -> get a link. The LAN sync only applies to the synchronized folders which is another use case.