Log and epochs

Each creator has an append-only history of membership, content and hosting events. Signed checkpoints bind that history to an authorised host; witness attestations make competing accounts of it comparable.

Entries

Every operation of consequence is an entry: a membership issued, renewed or revoked, content published, a manifest head advanced, an epoch opened or closed.

Entries are hash-chained. Each entry’s hash is computed over its own contents together with the hash of the entry before it, so an entry’s position is fixed by every entry that follows. Altering anything at one position changes every hash after it.

Heads

A head is a signed commitment to the whole chain up to a position. It names the stream, the epoch, the position, and the chain hash at that position.

It is signed by the host for the covering epoch and co-signed by witnesses over the same bytes.

Because the chain commits backwards, a head commits to the entire history, not only its last entry. Signing a head whose hash is not the true chain hash at that position is a detectable act rather than an ambiguity.

Time

Verification uses two forms of recorded progress:

• Log position: how far the accepted history has advanced.
• Billing period: the period through which membership has paid coverage, compared with the current period recorded in that history.

The verification calculation does not read wall-clock time. The same verified history and policy produce the same decision regardless of the machine’s clock.

Freshness is nevertheless a policy choice. A verifier specifies its witnesses, the required threshold and the permitted distance behind the latest evidence it can establish. Old evidence does not become current simply because its signatures remain valid.

If the history does not advance, passage of calendar time alone does not change the result. Real payment scheduling must therefore be related explicitly to the progression recorded in the log; the ordinal model is not a completed calendar-billing service.

Epochs

The log is partitioned into epochs. An epoch is opened by the creator naming the host permitted to write during it, together with the range of positions that host may occupy.

An epoch is closed by fixing the position and hash of its last entry. That closing head is the last thing the outgoing host is permitted to have written.

Epochs exist so that authority can end by arithmetic rather than by vigilance. Without them, ending a host’s write access would mean detecting and rejecting its writes indefinitely.

Export and import

A creator’s history moves between hosts as a self-contained export: the entries, the chain linking them, and the signed heads attesting to them.

The receiving host verifies offline before adopting anything:

1. Recompute the chain over the supplied entries.
2. Check every head signature under its claimed signer.
3. Check the final head’s hash equals the recomputed chain hash at that position.
4. Check epoch chaining — each open matches the close it claims to follow.
5. Check every entry falls inside the delegation covering its epoch.

A history that changes without matching the trusted signed commitments fails verification. A shorter, internally consistent history can still be old; completeness and freshness must be checked against the required checkpoint.

The receiving service must validate the export before treating it as its authoritative history. Durable adoption, interrupted writes and restart recovery are additional implementation responsibilities.

What the log is not

• Not a readable archive. Entries commit to content by hash; the content itself is sealed and stored separately.
• Not a public feed. Serving entries is a host function, subject to the same proofs as anything else.
• Not an analytics store. Its purpose is to make a specific set of claims checkable by a stranger.