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.

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 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.