# Blind peering
A **blind peer** is a dedicated replicator that stores and serves [Hypercores](/p2p/reference/building-blocks/hypercore) **without decrypting or interpreting** their contents. Blind peering is one way of **putting the server in serverless**: always-on reachability like a hosted service, but the operator never holds the plaintext. It joins swarms on request and caches blocks so other peers can find a source. Blind peering separates "make this core findable" from "I personally hold the plaintext."
For seeding your own application with `pear seed`, and for finding the keys behind a Pear app bundle, see [Availability and distribution](/pear/explanation/availability-and-blind-peering). This page is about the third-party replication service instead.
The stack has three parts:
1. **[blind-peer](/p2p/reference/helpers/blind-peer)**—server library that accepts peering requests and replicates cores.
2. **[blind-peering](/p2p/reference/helpers/blind-peering)**—client library used inside applications to register cores or Autobases with a blind peer.
3. **[blind-peer-cli](https://github.com/holepunchto/blind-peer-cli)**—CLI that runs a blind peer as a standalone server (provides the `blind-peer` command).
## Running a blind peer server [#running-a-blind-peer-server]
Since Pear 3.4.0, [`pear blind-peer start [--trusted-peer ]`](/pear/reference/pear/cli#pear-blind-peer) runs the same server natively—no separate install. Use it for a Pear-managed deployment; the standalone `blind-peer-cli` package below still applies for a plain Node/Bare process, or anywhere outside a Pear install. The command reference also covers `identity` (print this peer's own key) and `request` (ask a peer to seed something on demand).
Install the CLI and start the server:
```bash
npm i -g blind-peer-cli
blind-peer
```
On startup the process logs (as ndjson) a `Listening at ` line—that public key is the blind peer's identity, and clients use it as one of their configured `keys`. The default disk budget is 100 GB; cap it with `-m ` (megabytes).
For production, run `blind-peer` under a service manager. Example systemd unit:
```toml
[Unit]
Description=Blind Peer
After=network.target
[Service]
ExecStart=/usr/local/bin/blind-peer -m 10000 --trusted-peer
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
```
Pass `--trusted-peer ` to authorize a specific peer to announce on the blind peer (set `announce: true` on its requests). The public key here is the identity of the peer that will make those requests—the `Listening at ` value logged by that peer's own swarm node.
If that peer is a Pear machine rather than a standalone swarm node, it reads its own identity with `pear identity blind-peer-client`—see [Look up this machine's network keys](/pear/how-to/look-up-network-keys).
## Registering cores from an application [#registering-cores-from-an-application]
Wire the client to your app's existing [Hyperswarm](/p2p/reference/building-blocks/hyperswarm) and [Corestore](/p2p/reference/helpers/corestore):
```js
import BlindPeering from 'blind-peering'
import Hyperswarm from 'hyperswarm'
import Corestore from 'corestore'
const store = new Corestore(storage)
const swarm = new Hyperswarm()
swarm.on('connection', (conn) => store.replicate(conn))
const BLIND_PEER_KEYS = ['']
const blinds = new BlindPeering(swarm.dht, store.namespace('blind-peering'), {
keys: BLIND_PEER_KEYS
})
// Ask the blind peers to keep a single Hypercore available…
await blinds.addCore(core)
// …or a whole Autobase (all of its writer and view cores).
await blinds.addAutobase(base)
```
`addCore` / `addAutobase` connect to the closest configured blind peers and request that they replicate and seed the given cores—without the blind peer ever being able to read them.
For the common case of registering a single drive you're already seeding, [`pear seed --blind-peer `](/pear/reference/pear/cli#pear-seed) (since Pear 3.4.0) does this without writing any client code. Reach for the `blind-peering` client shown above when you need multiple cores, an Autobase, or control beyond a single seed session.
Consider letting users configure which blind peers they trust—default infrastructure may not match privacy or jurisdiction requirements (for example location-sensitive data).
## Trusted peers and discovery keys [#trusted-peers-and-discovery-keys]
When a blind peer runs with `--trusted-peer`, it recognizes seed requests signed by that key and joins the swarm for the requested core. That is more targeted than broadcasting blindly: peers looking for a specific core use its **discovery key** as a [Hyperswarm](/p2p/reference/building-blocks/hyperswarm) topic, so participants in that topic are likely to hold or want the same data.
Blind peering does not replace end-to-end encryption or capability checks on the cores themselves; it only improves **reachability** by keeping an always-on replica on the network.
## See also [#see-also]
* [Pear CLI: `pear blind-peer` and `pear seed`](/pear/reference/pear/cli#pear-blind-peer)—the platform-native commands, since Pear 3.4.0.
* [Availability and distribution](/pear/explanation/availability-and-blind-peering)—seeding your own application with `pear seed`, and finding the keys behind a bundle.
* [Keep data available with blind peering](/p2p/how-to/blind-peering/keep-data-available-with-blind-peering)—step-by-step walkthrough of the client library above.
* [Add blind peering to a chat app](/p2p/how-to/blind-peering/add-blind-peering-to-a-chat-app)—the same client layered onto a chat app worker.
* [blind-peering reference](/p2p/reference/helpers/blind-peering)—the client library's full API.
* [blind-peer reference](/p2p/reference/helpers/blind-peer)—the server library's options, events and limits.
* [Autobase reference](/p2p/reference/building-blocks/autobase)—multi-writer cores often registered with blind peering.
* [Hyperswarm reference](/p2p/reference/building-blocks/hyperswarm)—topic-based discovery blind peers participate in.