Corestore: many cores, one storage

Real apps juggle many Hypercores: yours, every peer's you follow, metadata
and blobs per drive. Corestore
manages them under one storage directory and — the key feature — derives
your writable cores deterministically from one primary key.

const Corestore = require('corestore')
const store = new Corestore('./storage')

// Writable: derived from the store's primary key + a name.
const feed = store.get({ name: 'p2pbuilders/user' })
await feed.ready()   // same name → same keypair, every launch

// Read-only: someone else's core, by public key.
const theirs = store.get(Buffer.from(theirKeyHex, 'hex'))

Why this matters:

• One secret to protect. Back up the primary key and you have backed up

every identity the app derives. This is p2pbuilders' whole identity story:
primary key on disk (mode 0600), user core derived as
(primaryKey, 'p2pbuilders/user').

• Namespaces compose. store.namespace('drafts').get({ name: 'log' })

lets libraries create cores without colliding with yours.

• Replication is one call.

swarm.on('connection', (socket) => store.replicate(socket))

Every core in the store syncs over that socket — but only cores both sides
already know the key for. Replication never leaks keys; discovery of which
cores exist is your app's job (gossip, invites, directories).

Habit to build: open cores through the store everywhere — never construct a
raw Hypercore with its own storage path once an app grows past hello-world.