Pp2pbuilders
learn › Build articles

7 min read · also at #/learn/build-relay

HiveRelay: dumb storage that keeps P2P online

Every app in our ecosystem leans on
HiveRelay: a fleet of
always-on nodes (5+ relays, 3 continents) that pin Hypercores so data
survives its author going offline —
the laptop-lid problem, operationalized.

The contract

A relay does exactly one thing: given a 32-byte key, replicate it and keep
serving it.
No indexing, no validation beyond Hypercore's own signatures,
no moderation, no accounts. This dumbness is a security decision:

untrusted mirror by construction.

selectively rewrite content without breaking signatures.

How apps use it

The client library speaks to the fleet: seed(pubkey) requests pinning
with a replica count; acceptances come back per relay with regions. The
p2pbuilders TUI seeds your core and every author you track on boot and
as discovery finds them — availability spreads with attention, invisibly.
The relays command shows who is pinning you right now.

For sites and app bundles, publish() wraps files into a Hyperdrive and
seeds it — both cores, after
the blobs-core incident.

Operational lessons

  1. Durability needs proof, not promises. Acceptance means "will try".

The publisher waits for evidence a relay holds the bytes
(waitForDurable) before it exits, and re-checks on a loop when asked
to babysit. Separately, an archive tier re-heals replicas (≥7 across ≥4
regions) without the publisher.

  1. Pins are leases, not tombs. TTLs plus periodic re-announce from live

clients keep storage bounded and data fresh — set-and-forget pinning
grows forever.

  1. Regions are part of the API. Acceptances report region codes so a

client can verify geographic spread instead of hoping.

The line we hold

Every feature request that would make relays smarter — search, feeds,
moderation — gets the same answer: that is edge work. The fleet stays a
cache tier apps prefer but never require. The moment peers cannot work
without relays, we have rebuilt servers with extra steps.

« One engine, two apps: porting to the browser Data patterns: logs, LWW, tombstones, sticky names »