Current release v0.24.3 · v0.25 in development

Go offline. Your app stays online.

Publish once from the peer-to-peer stack you already use. PearBrowser makes the release discoverable; HiveRelay confirms independent replicas so the same app key can stay reachable after you disconnect.

No permanent origin to babysit. The publisher can leave only after a relay accepts and verifies replication, and availability still depends on a reachable replica. Public releases may remain readable; configured sealed or P2P-only paths encrypt client-side and keep the data key away from relays.

See how it stays online ↓ Watch the explainer Read the source-tag quickstart

Same release key Verified replication before handoff No permanent publisher origin

Build your app Publish its release Pin verified replicas Share one stable key

Start with what you know

A familiar publish flow—without a permanent origin.

If you can package a Hyperdrive release, you already understand the hard part. HiveRelay adds discovery, replication confirmation, and a way to verify the handoff after your local process is gone.

App key = stable address Catalogue = discovery list Pin = availability request Relay = independent seeding peer

Build your release as usual.

Package the app and its manifest into a Hyperdrive. Its key is the stable address your users and peers will keep opening.

app + manifest → release key

Publish, then pin it.

Add the release to a PearBrowser catalogue for discovery and ask independent relays to replicate it. The flow completes only after an accepted relay confirms replication.

catalogue + confirmed pin

Share the key, not your uptime.

Close the laptop. Readers use the same key; reachable verified replicas keep seeding the release over Hyperswarm.

same key → reachable replica

Declared-public release optional HTTPS

Keep P2P delivery and, when you want it, add an HTTPS bridge for a normal browser URL.

Sealed or P2P-only release blind posture

Encrypt client-side and keep it off the public gateway. Relays handle ciphertext; the app retains its data key. Protocol metadata still exists.

Serverless for the publisher does not mean server-free: availability depends on a verified replica remaining reachable. Archive-tier repair is optional, policy-driven, and comes later.

HiveRelay, explained

Watch a normal publish become a verified handoff.

Start with the PearBrowser catalogue and publish flow, then follow the release through confirmed replication, public versus sealed delivery, and the operator dashboard. Optional OutboxLog comes last—because it is an app feature, not a prerequisite for getting online.

The flow: package a Hyperdrive, add it to a catalogue, request a pin, and wait for an accepted relay to confirm replication. Then choose normal public delivery with an optional HTTPS bridge or a sealed P2P-only posture. Experimental OutboxLog is a later, opt-in service for namespaced signed updates and catch-up.

Then, the headline

Four promises, translated into developer language.

Once the flow is familiar, the tagline stops being four new ideas at once. Each word describes a property you can inspect in the protocol, exercise in code, or observe in a running relay.

Serverless

You can stop running the origin.

After a verified handoff, the publisher can go offline while reachable independent replicas continue seeding the release.

Run the handoff →

Provably

The handoff leaves evidence behind.

Signed intents, receipts, commits, anchor proofs, and witness observations form a trail a client can verify rather than merely trust.

Inspect the guarantees →

Blind

Relays receive ciphertext, not your data key.

In configured blind mode, app data is encrypted before replication. Protocol and routing metadata remain visible, but the app keeps the key needed to read the body.

Read the threat model →

Hosting

Independent peers keep a release reachable.

Relays store, seed, and serve published Hyperdrives over Hyperswarm while they remain reachable; services are optional extras, not part of the basic delivery path.

See what runs →

Precise boundaries: “serverless” removes the publisher-operated origin; it does not make computers disappear or promise perpetual uptime. “Blind” describes configured blind or P2P-only custody paths, not public apps that intentionally publish readable data.

The proof trail

A custody handoff you can verify at every step.

The protocol turns “the relay has it” into signed state transitions, then gives clients and witnesses the material to challenge that claim.

1. Declare the handoff.

For configured blind custody, the publisher signs an intent over ciphertext identifiers, a retention window, and the required replica policy. Known plaintext fields are rejected before the protocol can proceed.

2. Collect independent receipts.

Relays accept the encrypted material and sign receipts. Custody commits only after the requested quorum is present, so logical source-retired state follows evidence instead of hope.

3. Challenge the claim later.

Fresh anchor proofs and custody possession proofs test current blind-custody state; witness tombstones record observed post-expiry behavior. They provide evidence of non-serving state, not proof that bytes were erased.

Under the hood

One stable key, four small moves.

The always-on outcome comes from a compact delivery path. Stronger custody, archive repair, witnesses, and app services remain explicit additions—not hidden requirements.

01 · ADDRESS

Package a Hyperdrive.

The release key remains the app's stable P2P address.

02 · DISCOVER

Add it to a catalogue.

A discovery record helps readers find that same key.

03 · REPLICATE

Request a relay pin.

Independent relays copy and seed the release over Hyperswarm.

04 · VERIFY

Leave after confirmation.

The handoff completes only after accepted replication verifies.

Optional by design: configured blind custody adds signed ciphertext handoff; archive tier can add policy-driven repair; app services load only when selected. None changes the basic catalogue-and-pin path.

Optional app tools

Use more relay capability only when your app calls for it.

The basic publish-and-pin flow does not require these. Everything below is an opt-in service your app can call over RPC, grouped by readiness so a first release does not have to absorb the whole catalog.

Core built-ins + production-ready

Start with the capabilities that have a clear job.

identity, storage, and schema are core built-ins. vrf provides production-ready verifiable randomness when its input is bound to immutable or external state.

The publish-and-pin path remains useful even when no app service is enabled.

Optional + privacy-gated

Add stronger storage tools deliberately.

storage-proof samples retrievable metadata blocks for non-blind drives; it does not cover blobs or prove sealed replication. Blind or redacted drives return NOT_SEEDED so the proof cannot become a possession oracle.

shard-store is an optional content-addressed path for custody shards.

Experimental preview

Keep evolving app features behind explicit selection.

ai, zk, sla, arbitration, notify, outboxlog, and poker are experimental—not production-ready defaults.

OutboxLog change events prompt catch-up; they are not app truth, and an append acknowledgement is not a custody receipt.

Services are opt-in and secure by default. Relay-only profiles run the availability and custody kernel without loading app plugins. Turn on only what an app needs, per relay:

// config.json — or the dashboard Services tab
{ "enableServices": true, "plugins": ["storage", "identity", "schema", "vrf"] }

Anonymous swarm peers receive the anonymous role and cannot reach admin routes unless explicitly allowlisted. Experimental bundles may pull declared dependencies; review the immutable source-tag documentation before enabling them.

Use cases

Concrete patterns the protocol enables today.

These are concrete protocol patterns documented in the current v0.24.3 release, published as an immutable GitHub source tag with zero attached assets—not generic “could be used for” categories.

Release boundary: HiveRelay's current product and source release is v0.24.3, with v0.25 in development. v0.24.3 is not published as npm/latest or a downloadable appliance; the app-agnostic blind-substrate replacement remains unreleased and is not described here as shipped.

Encrypted handoff with signed retention state

Send an encrypted blob to a quorum of relays and get signed receipts back. Recipients can verify custody before they unseal. The TTL is signed protocol state; after it passes, witnesses record whether a relay is observed serving or non-serving. That evidence does not prove forensic deletion.

Best for: document escrow, time-bounded serving policies, ephemeral sharing, and key custody with auditable retention state.

Public plaintext, blind custody

Encrypt content with a random key, store the ciphertext anywhere, then disperse the key as k-of-n self-verifying blind shards across independent relays. No single operator — and no k-1 colluding — can produce the plaintext; any k shards rebuild it at the reader's edge.

Best for: key escrow, secret custody, encrypt-and-forget archives, splitting trust across operators you don't control.

Auditable archive repair

Explicitly mark a drive archive tier (durability: 1) and AutoHeal can recruit replicas according to configured operator, region, and buffer thresholds. For a non-blind drive, proveSeeded can show that randomly sampled metadata blocks were retrievable from a named relay at a pinned head and nonce. It does not cover blobs or prove sealed replication.

Best for: package mirrors, public datasets, multi-region read replicas, and archives whose repair policy and sampled retrievability should be inspectable.

Verifiable randomness & selection

Given a fixed input, RFC 9381 ECVRF output and its selection result can be verified independently. Bind that input to immutable or external multi-party state to prevent key-holder grinding. The optional chained beacon publishes rounds the operator cannot grind or skip once the chain begins.

Best for: chain-free governance, fair queues and sortition, verifiable dispute panels, provably-fair games.

Privacy-preserving messaging & storage

Apps declare privacyTier: 'p2p-only' and the relay handles only opaque ciphertext—catalogs are redacted, the gateway returns 403, and peers receive the data key out of band. Signed custody possession proofs attest to the opaque commitment; public storage-proof is deliberately disabled for blind/redacted drives.

Best for: wallets, medical apps, encrypted messaging, identity storage — anything a user wouldn't want an operator reading.

Single-writer signed feeds for real P2P apps

The experimental pattern behind Peerit: an operator registers the app namespace and caps, each writer signs updates with its own app key, and outboxlog exposes current app-defined rows plus change markers that prompt catch-up. In a blind namespace, only client-sealed bodies pass; key exchange and recipient trust stay with the app.

Best for: P2P social and forums, activity feeds, audit logs, any app that needs relay-assisted sync but keeps its own truth.

A narrower trust boundary

Ordinary hosting gives you an operator. HiveRelay gives you a proof trail.

Both models run on real computers. The difference is what the publisher must operate, what the host can see, and which claims a client can verify independently.

Typical managed hosting

The publisher keeps an origin process or cloud account running.
Operator visibility depends on application-layer encryption.
Availability is usually reported through provider telemetry.
Retention and deletion are administrative controls.
Replica and operator diversity are usually opaque.
A public HTTPS endpoint is the expected route in.

HiveRelay custody

The publisher can disconnect after a verified handoff while a replica remains reachable.
Blind-mode validators admit ciphertext-only custody envelopes.
Signed receipts and proofs can be checked by the client.
Retention transitions and observed non-serving state leave signed evidence.
For archive-tier releases, policy-driven repair applies operator and region rules to verified replicas.
Anchor and custody channels run over Hyperswarm without public HTTPS.

For developers

A small client integration. No origin process to babysit.

Source example: this API shape is pinned to the current immutable v0.24.3 release. It is not published to npm; the unqualified client package resolved to npm latest 0.20.2 at evidence capture. HiveRelay v0.25 is in development.

import { HiveRelayClient } from 'p2p-hiverelay-client'

const app = new HiveRelayClient('./storage')
await app.start()
const drive = await app.publish('./my-app', { seed: false })
const accepted = await app.seed(drive.key, { replicas: 3 })
if (accepted.length < 3) throw new Error('Replica target was not accepted')

for (const { pubkey } of app.getSeedStatus(drive.key).relays) {
  const check = await app.verifySeeded(drive.key, { relay: pubkey })
  if (!check.complete) throw new Error(`Relay ${pubkey} did not verify`)
}

await app.destroy() // reachable, verified replicas can keep seeding

For atomic custody

const intent = await app.publishCustodyIntent(relayUrl, {
  blindContentId: hashHex(payload),
  ciphertextRoot: yourCiphertextRoot,
  requiredReplicas: 3,
  retainUntil: Date.now() + 24 * 60 * 60_000
}, { apiKey })

// Wait for quorum, sign commit, retire authority.
// Recipients can verify the chain later, without trusting you.

Quickstart tutorial → SDK reference → Pear / Bare integration →

For operators

Run a relay. Choose the role it performs.

Three roles, mix and match. Run all three, run one, or run a witness-only node.

Role	What you do	What you need
Custody Relay	Store encrypted ciphertext, sign receipts and proofs.	Storage
Witness	Probe other relays at expiry, sign tombstones.	A small VPS — no storage
Persistent Seeder	Host archive replicas; policy-driven repair manages diversity.	Storage + uptime

Package example at evidence capture: npm 0.20.2 · HiveRelay release: v0.24.3

npm install -g p2p-hiverelay
p2p-hiverelay setup

Operator guide → Dashboard source and docs →

Tested. Audited. Open.

Claims you can rerun yourself.

Automated protocol coverage

The trust stack includes unit and end-to-end integration suites, including a multi-relay Hyperswarm testnet that exercises the custody pipeline with real relay processes.

Repeatable simulation harnesses

An analytic model explores failure scenarios while a behavioral simulator drives the availability-repair scheduler against a deterministic in-memory network. Both are designed to rerun when behavior changes.

Apache 2.0 open source

The protocol, SDK, and reference implementation are open. Alternative implementations are welcome — the protocol is independent of any specific implementation.

Honest about what we can't do

The whitepaper is explicit: on commodity hardware, cryptography cannot prove a relay erased bytes. The protocol delivers logical source retirement and observed non-serving state, not forensic erasure. That boundary is documented, not hidden.

Operator evidence

State transitions as they happen.

Operator policy

bounded

Custody receipts

verified

Replica policy

satisfied

Anchor proofs

signed · fresh

recruit → operator distinct · anchor verified receipt → custody policy satisfied · committed witness → non-serving observation signed

Illustrative dashboard view. The operator interface surfaces replica policy, custody receipts, anchor proofs, and witness events from the relay's own state feed. Cryptographic artifacts remain the evidence of record.

Documentation

Read the protocol, not the pitch.

Everything is open and specified — every claim on this page traces back to a doc. Apache 2.0, all on GitHub.