# Availability and distribution



Peer-to-peer availability is not automatic. A new user can only download data that at least one online peer already holds. Pear applications therefore need an explicit strategy for [data availability](#data-availability) and [application availability](#application-availability).

<Callout type="info">
  This page covers seeding an application bundle with `pear seed` and finding the keys behind it. For the general distribution model, see [Storage and distribution](/pear/explanation/storage-and-distribution). For a serverless, third-party replication service that keeps cores available without you running anything, see [Blind peering](/p2p/explanation/blind-peering).
</Callout>

## Two availability problems [#two-availability-problems]

### Data availability [#data-availability]

Data availability means the [Hypercores](/p2p/reference/building-blocks/hypercore), [Autobases](/p2p/reference/building-blocks/autobase), or drives your application reads and writes remain reachable on the swarm. Chat history, shared documents, and room state all depend on someone seeding the relevant cores.

### Application availability [#application-availability]

Application availability means the Pear app itself—its metadata core and content [Hyperdrive](/p2p/reference/building-blocks/hyperdrive)—can be discovered and installed. A `pear://` link is stable, but the bytes behind it still have to exist on at least one peer.

Both problems share the same underlying constraint: replication requires a live source.

## Seeding with `pear seed` [#seeding-with-pear-seed]

The simplest way to keep an application bundle online is [seeding](#seeding-with-pear-seed), analogous to seeding a torrent. Running `pear seed pear://<app>` keeps the underlying cores announced and available for download.

```bash
pear seed pear://<app>
```

The process must stay running while you want to act as a guaranteed source. Anyone can open the link, but a first-time user needs at least one seeder with a complete copy.

<Callout type="info">
  See [Storage and distribution](/pear/explanation/storage-and-distribution#how-distribution-works) for how staging, seeding, and lazy replication fit together—this page does not repeat that model.
</Callout>

Seeding works well when you control an always-on machine and the cores you care about are ones you already possess. It has two practical limits:

1. **Operational overhead**—You need a running `pear` (or equivalent replicator) per application you seed.
2. **Scope**—You can only seed cores you have locally. A private room or direct-message thread you are not a member of cannot be seeded from your node.

When authors go offline and no participant keeps seeding, data can become temporarily unreachable even though the cryptographic keys still exist.

## Finding the keys to keep available [#finding-the-keys-to-keep-available]

`pear info pear://<app>` prints the keys behind an application bundle:

```bash
pear info pear://<app>
```

The `project` and `content` rows identify the metadata core and content drive. To keep them available, open the corresponding cores in a replicator process—either your own `pear seed` process above, or a third-party [blind peer](/p2p/explanation/blind-peering) you register them with.

## See also [#see-also]

* [Storage and distribution](/pear/explanation/storage-and-distribution)—on-disk layout and the `pear seed` distribution model.
* [Deploy your application](/pear/how-to/operate-an-app/manual-deployment/deployment)—staging and announcing releases.
* [Blind peering](/p2p/explanation/blind-peering)—a third-party replication service that keeps your cores available without decrypting them.
* [Peer-to-peer, demystified](/p2p/explanation/peer-to-peer-demystified)—how peers find one another on the swarm.