# Bootstrap and signaling

Cursors needs places where people and bodies can find one another. Those places must improve availability without becoming identity authorities.

## Small first body

`/boot/` is generated after every production build. Its HTML response body must remain at or below 1,200 bytes, enforced by `npm run check:bootloader`. That is small enough to target one ordinary TCP payload, but the application does not claim literal one-packet delivery: TLS records, HTTP headers, MTU/MSS, congestion state, intermediaries, and retransmission are outside an HTML file's control.

The tiny body first checks Cache Storage for a previously installed `core.mjs`, then falls back to the content-hashed release entry bundled beside it. A future native or service-worker body can place a signature-verified core in that cache after retrieving it from an invited peer, encrypted swarm, removable capsule, or HTTPS webseed. The cache name is a location, not a trust decision: content and release signatures still require verification before installation.

A first-ever stock browser with an empty cache cannot contact BitTorrent DHT, establish an authenticated peer session, or verify a large runtime using no code. It must receive the bootstrap from some reachable source. Resurrection therefore names multiple independent sources and pins trust; it does not pretend the original host is mathematically unnecessary at the first byte.

![Discovery versus authority](images/discovery-trust.svg)

## Core rule

**Addresses answer where to try. Keys answer whom to trust.**

TLS, DNS, IP addresses, app stores, QR codes, package mirrors, and rendezvous servers can all deliver signed hints. None may silently replace a Self, world, peer, or project key.

## Signed bootstrap manifest

A release may embed several bootstrap public keys and a last-known manifest. The manifest contains:

- protocol and manifest versions;
- a monotonic epoch;
- validity and refresh intervals;
- rendezvous endpoints across independent domains/providers;
- transport descriptors rather than one hard-coded URL scheme;
- DHT namespaces and LAN discovery labels;
- project/release key successors;
- the previous manifest hash and optional next-key commitments;
- signatures from the currently accepted bootstrap threshold.

The example in [`bootstrap/example-manifest.txt`](../bootstrap/example-manifest.txt) is explanatory and contains no live key or trusted endpoint.

## Domain seizure

If an attacker seizes a bootstrap domain but not its signing keys, the attacker can:

- censor responses;
- replay data unless clients enforce epoch and expiry;
- redirect clients to hostile transport endpoints;
- observe connection attempts.

The attacker cannot:

- impersonate a pinned project key or a user's Self;
- issue a valid successor manifest;
- forge peer introductions;
- decrypt end-to-end sessions solely from domain control.

Availability mitigations include cached manifests, multiple operators, DNS plus DHT plus LAN/invite discovery, reproducible release pins, QR codes, friend introductions, and signed successor chains.

## Rendezvous server knowledge

A minimal signaling service should learn as little as possible:

1. a rotating rendezvous token derived for one relationship or room;
2. short-lived encrypted connection candidates;
3. proof that the sender may publish under that token;
4. no plaintext world name, cursor contents, capability body, or social graph when avoidable.

Peers authenticate end-to-end after rendezvous. A server can introduce or relay bytes but cannot mint accepted identities.

## Shipping policy

Do not bake private keys, private infrastructure credentials, or a single mandatory domain into clients. Bake public trust anchors only after an explicit key ceremony and publish a recovery procedure before inviting real users.