# Resurrection capsules

**In plain language:** one link or QR code should be enough to tell a fresh Cursors body whom to trust, which signed horizon to recover, and several independent places to ask for the bytes. The capsule is a map and a set of trust pins—not a secret key, a database dump, or permission to execute.

This is how a dry network can rehydrate without making `curso.rs`, Cloudflare, GitHub, DNS, or one DHT server irreplaceable.

## Capsule contents

A compact edge capsule may carry:

- format and protocol version;
- root/release public-key fingerprint and minimum accepted epoch;
- signed release-head hash and optional predecessor hash;
- world or cursor horizon cryptopointer;
- signed BEP44 directory public key, salt, and minimum sequence;
- torrent infohash or content root for encrypted immutable blocks;
- peer, LAN, DHT, tracker, webseed, mirror, IPFS-like, or removable-media hints;
- expiry and successor commitments;
- the capsule issuer's signature when the capsule itself makes claims.

It must not carry Self private keys, manifest decryption keys, bearer capabilities, session cookies, Cloudflare credentials, GitHub tokens, or plaintext private mailbox contents.

## Peer-first recovery order

1. Inspect the capsule before joining anything.
2. Verify the pinned release or bootstrap signature and reject rollback below the minimum epoch.
3. Ask already-known local peers and LAN bodies for the content-addressed head.
4. Ask independent peer discovery and signed DHT directories.
5. Request hash-verified ciphertext blocks from torrent peers and HTTP webseeds in parallel.
6. Use mirrors, rclone-backed stores, GitHub release artifacts, or `curso.rs` only as replaceable carriers.
7. Decrypt only with separately held invitation material.
8. Rebuild SQLite operational indexes from verified records and mailbox checkpoints.
9. Announce availability only under the body's admitted rights and resource budget.

Browsers cannot directly speak UDP DHT or ordinary TCP BitTorrent. A browser body therefore needs WebRTC/WebTorrent peers, HTTPS paths, or an admitted encrypted WebSocket relay. Native bodies can add DHT, TCP, µTP, local disks, and removable media while preserving the same signed heads.

## The zero-copy limit

A QR code can preserve identity and directions, but not arbitrarily many missing bytes. If every independent copy of a release, checkpoint, or encrypted block is gone, no protocol can reconstruct it. “Resurrectable” therefore means:

- tiny roots and manifests fit in many durable places;
- larger content is replicated across independent peers and stores;
- fountain-coded recovery tolerates partial loss;
- the capsule names more than one administrative and transport domain;
- a new body can verify every recovered object before accepting it.

## Refresh without host trust

A body should not reload merely because the hosting origin changed. It fetches a candidate release head, verifies its accepted signing threshold, epoch, expiry, predecessor link, and content root, then offers a refresh. A completely unenrolled viewer may auto-apply only a release that chains to an embedded or previously pinned clean root.

Unverified forks stay visibly non-canonical. Their boot screen must offer the named fork issuer, pinned horizon, and a clean-start choice from the latest accepted release.

## Keep the capsule small

The QR form should contain a short versioned binary or base64url edge record plus a checksum. Large endpoint lists live behind the signed release head. The same capsule can be printed, copied as a hyperlink, embedded in a torrent comment, stored in a mailbox, or spoken as a short recovery code with error correction.

The repository now includes a strict edge codec using the prefix `cursors-resurrection:v1:`. It accepts only a raw Ed25519 release public key, minimum epoch, SHA-256 release head, cursor horizon, expiry, and one through twelve public retrieval hints. Unknown fields—including anything named like a private key—are rejected. The JSON/base64url edge is transport convenience only; accepted authority still comes from the signed release head and canonical Cursors records it locates.

## Proving that a write is durable

“Write requested” is not “durable.” The repository now includes a portable durable-write coordinator in `operations/durable-write.js`. A caller supplies content bytes, their expected SHA-256 content ID, copy and failure-domain thresholds, and small write/read adapters for the stores that body actually controls.

For every target the coordinator:

1. writes the immutable bytes;
2. reads them back through that target’s adapter;
3. hashes the recovered bytes;
4. counts the copy only when the read-back hash matches;
5. reports failed and missing targets without pretending they succeeded.

A result becomes `durable: true` only after it satisfies both the requested number of copies and the requested number of independent failure domains. Two copies on one disk, host, provider, account, or administrative domain do not satisfy a two-domain plan. Only verified targets contribute public retrieval hints to the resurrection capsule.

The coordinator is deliberately adapter-based. Browser storage, a nearby peer, an HTTPS webseed, rclone, removable media, R2, GitHub artifacts, or a native filesystem each need a real adapter with their own credentials and policy. The core never embeds those credentials and never treats a remote acknowledgement as proof without hash read-back.

See [Bootstrap](bootstrap.md), [Signed swarms](signed-swarms.md), and [Storage machinery](storage-machinery.md).