Get up and running.

Install & launch

Get desktop builds from the download page (or the v0.8.0 release page): macOS .app.zip, Windows .msix, Linux .AppImage. These are package-proof artifacts, not public-trust installers: verify them with SHA-256; Developer ID/notarization and Windows signing remain in progress.

# Download & verify (example)
shasum -a 256 PearBrowser-0.8.0-macos-arm64.app.zip

Legacy migration identifier: tco5k7h38uoxatedp1wongdbhjxow1x7jiwm3t1i9cujbebhsbty

The native package carries the desktop shell. The legacy Pear key identifies an older installation only: it is not a v3 launch command and is never supplied to PearRuntime.run(). You can open the P2P edition of this website at hyper://03f0060a35451cfb6b68ad1dda1b8474ebb43fd9100071ccf7d67679a83ebb4f/.

Address schemes

The URL bar understands more than https://:

• hyper://<key>/ — a Hyperdrive site or app, addressed by its 64-hex public key and served by whoever is seeding it.
• Older installations are recognized by a local migration identifier; it is not a browser address or app launcher.
• pearname://<name> — a memorable name resolved through the naming layer (below). Typing a bare word like keet triggers the same resolver.

Whenever a name resolves, a small provenance chip appears next to the address showing how it resolved (your saved name, the registry, a contact, or the curated floor) — the address never lies about where it came from.

Your identity

On first run PearBrowser generates a local identity from a BIP-39 12-word phrase. That phrase is your whole identity — back it up (Settings → “Moving to a new device?”) and you can restore on any machine.

Per-app sub-keys

Every site you grant a sign-in gets its own derived appPubkey — sites never see your root key, and Settings → Connected Apps lists and revokes each grant individually.

Lighthouse search

Pages you browse are tokenized and indexed locally, so Library search returns in under 5ms with zero network. To widen it, flip the “Include trusted peers” toggle: your local results paint first, then verified contacts' results arrive over the swarm and merge in, each with a provenance badge (you / trusted · hop N). Every peer row is re-verified and dropped if it doesn't check out.

P2P names Experimental

Enable “Names” in Settings → Experimental, then claim a name in Settings → Name registry by pairing it with a drive key. After that:

• Type the name (or pearname://name) in the URL bar and it resolves to your drive.
• The resolver checks, in order: your private petname → your own registry claims → names your trusted contacts claimed → a curated floor.
• Claims are owner-signed and durable across your devices; confusable look-alikes (e.g. a Cyrillic раypal) are rejected.

Use the Copy button on any claim to share it as pearname://yourname.

Nostr identity & feed Phase 3

Settings → Nostr identity shows your npub (seed-derived, stable across devices). Click “Link (attested)” to cross-curve-bind your Nostr key to your Pear root — a mutual attestation, revocable at any time.

Posting & reading

In Settings → Nostr feed, compose a note and it's signed with your Nostr key and stored in your local event log. Toggle “Include trusted contacts” to also see notes a verified contact authored with their attested key, replicated peer-to-peer. Every contact note is author-checked against the root you vouched for; there are no public relay servers in the loop yet.

Trusted contacts

The trust graph behind search, names, and your feed is your contacts. In the Library's “Trusted peers” panel, copy a signed contact invitation and paste a friend's. The invitation carries their public key, name, signature, and binding key, and is rejected if the signature doesn't verify. One verified contact then powers all the federation.

Publish a site or app

PearBrowser includes a site builder and a decentralized app catalogue. Create a site, publish it, and it becomes a Hyperdrive addressed by key. Publish browser content as hyper://; native apps need a signed release, platform artifact metadata, and an explicit local install flow. HiveRelay can replicate either content or release artifacts, but it does not attest binaries.

• Build & publish from the Sites tab.
• Your site is reachable at hyper://<your-key>/ the moment a peer (or HiveRelay) is seeding it.
• Package browser content as a browsable Hyperdrive. Package native apps as signed local artifacts, then request HiveRelay replication so the declared bytes remain available after your machine goes offline.
• Publish the catalogue entry with its kind, source, version, provenance, and platform support. People can open sites or review and install compatible signed native apps; a catalogue value never executes remotely.

Privacy & relays

PearBrowser ships without telemetry or remote analytics. History and local page indexing are off by default, while Content Shield, HTTPS-only navigation, tracking-parameter stripping, third-party cookie blocking, and fingerprint farbling are on by default. Read the plain-language privacy promise for the complete scope.

PearBrowser is P2P-first: the proxy tries peers and can use a HiveRelay HTTP gateway for availability. HiveRelay is a replication point, not an authority—signed records are re-verified client-side. Websites, relays, and peers may still receive network metadata such as your IP address and requested content. Some HiveRelay operators can expose Tor endpoints, but PearBrowser Desktop does not yet route browser traffic through Tor automatically.

Troubleshooting

“Could not reach backend”

Use the native package listed on the download page. If an older legacy installation needs recovery, keep its data intact and use the migration guidance rather than retrying a removed launch command.

Experimental features are off

Naming, device sync, and some Nostr surfaces are gated behind toggles in Settings → Experimental. They're off by default and clearly scoped — turn them on there.

Still stuck?

The source, releases, and issue tracker live on GitHub.