Hyperdrive: a filesystem on two cores

Hyperdrive gives you a
versioned file tree you can replicate like everything else. It is how Pear
apps ship and how P2P sites (this app's web build included) are hosted.

const Corestore = require('corestore')
const Hyperdrive = require('hyperdrive')

const drive = new Hyperdrive(new Corestore('./storage'))
await drive.ready()

await drive.put('/index.html', Buffer.from('<h1>hi</h1>'))
const buf = await drive.get('/index.html')
for await (const entry of drive.list('/')) console.log(entry.key)

console.log(drive.key.toString('hex'))   // share this — hyper://<key>/

A reader opens the same drive by key, replicates over swarm connections, and
reads files sparsely — a 2GB drive costs a reader only the files they touch.
Drives are versioned; drive.checkout(n) gives you an old snapshot.

The part everyone misses

A Hyperdrive is two Hypercores.

A metadata core — a Hyperbee mapping paths to

entries.

A content (blobs) core — the actual file bytes.

drive.key is the metadata key. Anything that pins "the drive by key" —
a relay, a mirror script — may replicate metadata and never fetch the bytes.
The drive looks alive (listings work!) but every read fails once the
publisher goes offline.

const blobs = await drive.getBlobs()
console.log(blobs.core.key.toString('hex'))   // pin THIS too

We shipped that bug and wrote it up:
Seed the blobs core, not just the metadata. If you host
anything on drives, read it.