Delegation and switching

A host serves a creator under an explicit grant. The grant determines which actions clients may accept and how the creator can replace the service.

Bounded grant

A host signs memberships, content items and manifest heads. Its authority to do so is a host delegation fixing:

• the single epoch covered
• the inclusive range of log positions it may occupy

Validating any host-signed object therefore includes:

1. The signature verifies under the host’s key.
2. A delegation for that host exists for the object’s epoch.
3. The delegation names the same creator as the record.
4. The object’s log position falls inside the delegated range.

Failing 2, 3 or 4 means the object is outside the delegation — the signature is real and the object is still invalid. Every party performs this check independently, including member devices.

What that buys is the difference between “the responsible party would notice and intervene” and “it does not verify.” Only the second survives the responsible party becoming the problem.

Switching hosts

Four signed steps, all authorised by the creator root:

1. Close the current epoch. This fixes the last position and hash. A forced close is signed by the creator root and requires no cooperation from the outgoing host.
2. Open the next epoch. The open names the new host and chains to the close. A new delegation fixes the new bounds.
3. Transfer the history. The new host verifies the export offline before adopting anything — see Log and epochs.
4. Re-point the name. A creator record with a higher sequence number and the new delegation commitment is published to the directory.

Witness-held checkpoints support a creator-authorised close without the outgoing host’s permission. Completing the transfer also requires available history, content and creator-held secrets. A forced close cannot reconstruct missing data; a move from an unreachable host requires those materials to survive elsewhere.

What survives

The intended continuity across an epoch boundary is:

• Memberships remain valid, unchanged. No reissuance. Each still verifies, with the same bytes, under the same member key.
• No membership rewrite on member devices. A host change alone does not require a new membership or identity. Clients still need acceptable routing and history evidence for the replacement service.
• Billing continues on the same period ordinals.
• Sealed content stays readable by whoever could already read it. The audience key was never the host’s, so replacing the host removes no access.

Mid-period switching is the case the design has to carry. A host that can only be left at a convenient moment cannot really be left, because the inconvenient moment is exactly when leaving matters.

What the outgoing host keeps

Its copy of the history up to the close, and the sealed blobs it was storing.

Neither is a disclosure: the entries were always its to hold, and the sealed content was never openable by it.

The close ends its authority to extend the accepted history. Clients with sufficient current evidence reject later actions outside that authority and follow the updated directory record. A client with only an old view cannot learn the change without obtaining newer evidence.