Hosting and moving

Why hosting, and not a relay

Direct calls need the recipient’s server reachable. The hours it is not are answered by the thing a person-held root makes safe: being hosted. A host runs the identity’s server all the time, under a leaf the person issued, and can be replaced without the person losing anything. There is no relay role and no store-and-forward gateway that would see every sender, recipient and timestamp for its trouble: a node delivers directly and, when the peer stays unreachable until expires, reports failure (§ 9, § 7).

What a host holds, and never holds

The leaf certificate for the identity at its endpoint and that leaf’s private key; a superseded leaf’s key until its notAfter; the identity’s data — contacts, threads, media, invites, settings, audit chain. Never the root. A leaf’s key does not outlive its leaf: a host stops using the key of a leaf that has expired and destroys it, keeping only the key id so that an envelope still sealed to it is answered certificate_renewed (§ 9, § 14.4). A provider hosting many people holds one leaf per identity, issued by each customer’s own root for the address the provider serves it at; a customer who leaves issues a leaf to the next host, and the provider deletes what it held (§ 10).

Moving

Moving is the person issuing a leaf to the new host, the data carried across as an archive — the person’s contacts and their conversations, with the media in them, and nothing that is the host’s own — and the new host reaching every contact by update_contact before the person tells the old host to leave, so that no contact meets a gap. The archive is the export of § 9.2: one unencrypted zip that holds no key of any kind, which the importer checks whole before it writes anything, shows the person contact by contact, and closes with a new leaf from the person’s wallet (§ 9). At each contact, the receiver validates the new chain to the root it pinned — so this is provably the same person — and either re-pins at once or asks its owner, per accept_new_hosts (§ 5.3). Certificates and renewal explains why the old host’s leaf then proves nothing.

What a host must do when the person leaves

Destroy the leaf’s private key and delete every record of the identity at once, keep nothing beyond what law compels, and answer calls at the old address exactly as it answers calls for an address it never served. The protocol’s backstop against a host that does not is the leaf’s own expiry, and the fact that a newer leaf outranks it with every contact it reaches. An address an identity has vacated is not assigned to another identity until the last leaf issued for it has expired, so a contact that missed the move never reaches a stranger where it expects a friend (§ 9).

The wallet on the other side

The wallet holds the root and nothing a host holds. It signs certificates only from an explicit user action, in a window of its own that no page can draw over, showing the endpoint the leaf will name, the origin of the page that asked, whether it has issued to that host before, and the validity. It issues one live leaf per identity at a time — a second endpoint is a move, not a second home — and keeps its own copy of the person’s contact book, so the book outlives any host (§ 9). A host asks it with a signing request: a form submitted by top-level navigation, answered with the chain in the fragment of the host’s own address (§ 9.1).