We Gave Our Word Processor's Hub RAID-0 Across Laptops — in One Session

Last week we shipped a full word processor built with Claude in a single session, and it came with a party trick: the Hive Hub, a 0.6MB zero-dependency Node script that turns any PC into a wireless document server for every laptop on the Wi-Fi. Open one address, get the whole app and a shared document drive. No switch, no cables to each machine, nothing installed on the clients.

It had one honest limit, and we said so at launch: one hub is one PC's disk. The shared drive was exactly as big and as fast as the single machine running the script. This is a field report on how we removed that ceiling — how we gave the hub RAID-0 across laptops in one working session, and the surprisingly small amount of code it took. If you build with Claude, the interesting part isn't the feature; it's how cleanly a distributed-systems problem decomposes when you let the model implement a spec you've frozen first.

The problem: one hub is one disk

Picture the room this is for: a small shop with three or four older laptops, a Wi-Fi router, and no budget for a Synology box or a Cisco switch. The v1 hub already gave them a network drive with zero hardware. But every document lived on one machine. Run out of space, and you're done. Want that machine's disk and the spare laptop's disk to add up into one bigger drive? Couldn't do it.

What they actually wanted is what a NAS gives you and a single script historically doesn't: pool several machines' disks into one drive whose capacity is the sum, or keep a full copy on every machine so any one can die. That's RAID-0 and RAID-1. The question was whether we could get there without a database, without a coordinator node, and without adding a single dependency to a script whose whole pitch is that it has none.

The design: a hash ring over self + peers

The trick to distributing data with no central index is to make the placement deterministic. If every node can compute, from the document ID alone, which node owns that document, then nobody needs to be asked and no map needs to be kept in sync. That's a consistent-hash ring, and it's the core of the whole feature.

Each hub is configured with its own public URL plus a list of peer URLs. It builds one sorted array — [self, ...peers] — and that's the ring. To place or find a document, it hashes the ID and picks a node by that hash:

// The entire placement rule. No coordinator, no index.
const ring = [self, ...peers].sort();          // every node builds the same ring

function ownerOf(docId) {
  const h = sha256(docId);                      // stable, uniform, cheap
  const idx = parseInt(h.slice(0, 8), 16) % ring.length;
  return ring[idx];                             // the node that owns this doc
}

Because sha256 is stable and uniform, document IDs spread evenly across the ring, and every node computes the identical owner for a given ID. A save request that lands on node A but hashes to node C is simply forwarded to C. A read works the same way. The client laptop never knows or cares which machine physically holds its file — it talks to whichever hub it opened, and the ring does the routing underneath.

That's the whole placement brain. Everything else is plumbing around it: forward when you're not the owner, store when you are, and stream the result back.

Local-only pooling endpoints

Nodes talk to each other over a small set of /api/pool/* endpoints — put a document, get a document, list what a node holds. Two rules keep that safe and prevent it from eating itself.

First, every peer call is authenticated with a shared secret. Pooling only activates when each machine is started with the same secret (and a Pro key). A hub will not accept a pool request that doesn't carry it, so a stranger on the network can't inject or read pooled documents.

Second — the bug we designed out before it could happen — the pooling endpoints are local-only. The public document API is what routes by hash and may forward to a peer. The internal /api/pool/* API always acts on the local disk and never forwards. If the pool endpoints could re-route, a request could bounce node A → C → A → C forever. By making the internal layer terminal, forwarding happens exactly once, at the public edge, and the private layer is a plain local read or write:

// Public API: may forward by hash
PUT /api/docs/:id      ->  owner = ownerOf(id)
                           owner === self ? poolPut(id) : forward(owner, id)

// Pool API: LOCAL ONLY, never forwards (kills recursion) + secret-authed
PUT /api/pool/:id      ->  requireSecret(req); writeToLocalDisk(id)
GET /api/pool/:id      ->  requireSecret(req); readFromLocalDisk(id)

That split — public layer routes, private layer is terminal — is the one non-obvious decision in the whole thing, and it's what makes a ring of peers safe to reason about.

Stripe vs mirror: capacity or redundancy

With placement solved, the two RAID modes fall right out of the same ring — you're just choosing how many nodes own each document.

• Stripe mode = RAID-0. Each document lives on exactly one node, chosen by the hash. Documents spread across every machine, so their disk space and their throughput add up. Three old laptops become one drive with the combined capacity of all three. This is the "pool my spare disks into something bigger" mode.
• Mirror mode = RAID-1. Every document is written to every node. You trade the capacity gain for redundancy: any one machine can be unplugged, catch fire, or wander off with an employee, and every other machine still has a complete copy.

Same ring, same secret, same endpoints. The mode is just the policy for how many owners a write fans out to. That's the payoff of getting the placement primitive right first — the "features" become one-line policies on top of it.

The honest RAID-0 tradeoff

Field reports that skip the caveats are ads, so here's the one that matters: pure stripe has no redundancy. That's not a bug we'll patch — it is literally what RAID-0 is. If a striped node is powered off, its share of the documents is unavailable until it comes back. Nothing is lost — the files are sitting on that machine's disk waiting — but they're hidden while the node is down.

We verified both behaviors with real multi-node clusters, not a mocked-out unit test: a striped ring where documents genuinely distributed across the machines and a downed node cleanly dropped only its own share, and a mirrored pair where we killed a node and the survivor still served the document with zero data loss. We're not going to quote you throughput numbers or node counts we didn't measure under conditions you'd care about — but the modes do what the RAID names promise, and we watched them do it.

A peer is just a URL

Here's the part that quietly makes this more than a LAN toy: in the ring, a peer is nothing but a URL. The placement math doesn't know or care whether that URL is a laptop two feet away on the same Wi-Fi or a hub sitting behind a port-forward or a tunnel in another building.

So the same pool can be on-prem, off-prem, or a combination. Put two laptops in the shop and one always-on box at home behind a tunnel into the same ring, and the mirror now keeps an off-site copy automatically — an off-site backup with no cloud subscription and no backup software, just another URL in the peer list. The secret still gates every call, so exposing a hub to the internet doesn't expose your documents to it.

And all of this is still the same zero-dependency Node script. No database, no message broker, no service mesh. sha256 is in Node's standard library; the ring is an array; the peers are strings. The entire distributed layer is small enough to read in one sitting, which is exactly why it was tractable to build against a frozen spec in a single session — the same contract-first approach we used to build the word processor itself.

The takeaway

The lesson isn't "Claude can write a distributed file store." It's that a genuinely hard-sounding problem — pool the disks of several laptops into one drive, with no coordinator and no dependencies — collapses into a hash function, an array, and a rule about which layer is allowed to forward. Freeze that spec, and the model implements it cleanly the first time.

The result is a real answer to "we need a network drive but not a $600 NAS": RAID-0 for capacity or RAID-1 for redundancy, over your own Wi-Fi, on hardware you already own, with a 0.6MB script and nothing installed on the client laptops. It's a Pro feature in the Hive Hub — you point it at the machines, hand each one the shared secret, and pick a mode.

And if you want to judge the quality of a ClaudeFarm build before you spend a cent, start where we make you spend nothing: the free context-budgeter skill is a complete, working crop given away so you can see how we write the ones you pay for — and the Skill Farmer's Toolkit ships the production skills our own agents ran during builds like this one. One payment, no subscription. Same as WriteHive.