Search code examples
distributed-computingserverless-architectureipfsgossiphyperdrive

What are the differences between IPFS and hyperdrive?


A year ago I attended Munich meetup where I first saw hyperdrive project live, and found it impressive. I also recently stumpled upon IPFS –the InterPlanetary file system– and I wonder about the differences. It's easy to have a lot of repercusion when starting a project like this in California, so I guess they might be similar projects but still don't understand the scope of hyperdrive fully.

I very much like the API and implementation hyperdrive, so if I had to build an app over a distributed file system I believe it would be easier for me at this point to chose that project.

Is there anywhere or some bold bullet points I could use for comparison?

Thanks


Solution

  • Some specific differences between IPFS and hyperdrive, considering both as mechanisms for sharing files and directories of files between peers in a distributed fashion are that:

    • IPFS has a global namespace (a given chunk or file with a specific hash can be used or accessed in any context), while hyperdrive files and chunks are scoped to individual drives. This is a bit of a generalization, but by default a file appearing in multiple hyperdrives will be downloaded over the network for each drive.
    • A connection to the IPFS network is usually persistent (eg, with a local daemon running that applications talk to, instead of talking directly to the network). There is no single dat or hyperdrive network, only peer swarms interested in specific drives; hyperdrive applications typically discover and connect to peers on their own.
    • Discovery and reference to hyperdrives is based on public key encryption (the keypair generated by the creator), while IPFS uses content hashing (meaning, in theory, it doesn't matter who added a given file or chunk to the network)
    • IPFS's merkel tree implementation does a better job de-duplicating between slightly modified copies of the same file. Hyperdrive files are stored as single contiguous chunks; even a small append to an existing file requires re-writing the same file to the feed. It's possible for hyperdrive to evolve to handle this de-duplication in the future.

    Subjective observations:

    • hyperdrive's current tooling for efficiently synchronizing entire directories of files between many peers is more polished (this is a core use-case for hyperdrive, and one of many use-cases for IPFS).
    • As of March 2018, there exists a usable web browser with native support for hyperdrive (Beaker Browser), and not for IPFS. Browser support for IPFS is likely to emerge in the next year, but will probably not be as ingrained to start (eg, will start with read-only).
    • IPFS's core libraries and tools have been ported to more languages, and have seen more review and development than hyperdrive.