@openvtc/trust-tasks 0.18.3 → 0.18.5

package/dist/rooms/owner/anchor/0.1/payload.d.ts

@@ -0,0 +1,537 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/owner/anchor/0.1/payload.schema.json
+ */
+import type { DataCommitment, DigestMultibase, EpochAnchor, Ext, HeadVersion, RecordCount } from "../../../../_shared/components.js";
+/**
+ * TODO: what the request payload of rooms/owner/anchor carries. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.
+ */
+export interface RoomsOwnerAnchorPayload {
+    /**
+     * The room to anchor. The recipient MUST hold its group state and MUST be able to update its DID.
+     */
+    roomId: string;
+    /**
+     * The host to read the room's head from, as a DID.
+     *
+     * The owner holds **one** of the three values it is about to publish. `rooms/epoch/mint`'s response is `{roomId, epoch}` — no watermark, and no reason there should be one: minting acts on the epoch, while the watermark and the commitment are facts about the room's *records*, which live at the host. So an anchor is assembled from a read, and this names where.
+     */
+    host: string;
+    /**
+     * The room's signing key, named rather than looked up: nothing maps a DID to its key, and a wrong key fails to verify against the room's own document at first use.
+     */
+    signingKeyId: string;
+    /**
+     * Ecosystem-defined extension members per SPEC.md §4.5.1.
+     */
+    ext?: Ext;
+}
+/**
+ * Success response to rooms/owner/anchor. Type https://trusttasks.org/spec/rooms/owner/anchor/0.1#response.
+ */
+export interface RoomsOwnerAnchorResponsePayload {
+    roomId: string;
+    /**
+     * What was written — returned so an owner can see it without resolving their own room, and so an operator can compare it with what a member later reads.
+     */
+    anchored: EpochAnchor;
+    /**
+     * The `did:webvh` log entry the anchor rode. This is what makes the anchor *witnessed*: naming the entry lets anyone fetch it and check the witnesses' signature over it.
+     */
+    versionId: string;
+    /**
+     * Whether the host's own listing reconciled with the `recordCount` it committed to, at the moment this was read.
+     *
+     * `false` is a host contradicting itself, and the anchor was still written — deliberately. An owner that refused to anchor a suspect room would leave it with no witnessed statement at all, which is the position the host benefits from. What is published is *what the host claimed*, and this member records that the owner had already caught it claiming something inconsistent.
+     */
+    reconciled?: boolean;
+    ext?: Ext;
+}
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { DataCommitment, DigestMultibase, EpochAnchor, Ext, HeadVersion, RecordCount };
+/** Trust Task type URI. */
+export declare const TYPE_URI: "https://trusttasks.org/spec/rooms/owner/anchor/0.1";
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsOwnerAnchorPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/rooms/owner/anchor/0.1#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsOwnerAnchorResponsePayload;
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export declare const PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $id: "https://trusttasks.org/spec/rooms/owner/anchor/0.1";
+    readonly title: "Rooms Owner Anchor — payload";
+    readonly description: "TODO: what the request payload of rooms/owner/anchor carries. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["roomId", "host", "signingKeyId"];
+    readonly properties: {
+        readonly roomId: {
+            readonly type: "string";
+            readonly description: "The room to anchor. The recipient MUST hold its group state and MUST be able to update its DID.";
+        };
+        readonly host: {
+            readonly type: "string";
+            readonly description: "The host to read the room's head from, as a DID.\n\nThe owner holds **one** of the three values it is about to publish. `rooms/epoch/mint`'s response is `{roomId, epoch}` — no watermark, and no reason there should be one: minting acts on the epoch, while the watermark and the commitment are facts about the room's *records*, which live at the host. So an anchor is assembled from a read, and this names where.";
+        };
+        readonly signingKeyId: {
+            readonly type: "string";
+            readonly description: "The room's signing key, named rather than looked up: nothing maps a DID to its key, and a wrong key fails to verify against the room's own document at first use.";
+        };
+        readonly ext: {
+            readonly $ref: "#/$defs/Ext";
+            readonly description: "Ecosystem-defined extension members per SPEC.md §4.5.1.";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["roomId", "anchored", "versionId"];
+            readonly description: "Success response to rooms/owner/anchor. Type https://trusttasks.org/spec/rooms/owner/anchor/0.1#response.";
+            readonly properties: {
+                readonly roomId: {
+                    readonly type: "string";
+                };
+                readonly anchored: {
+                    readonly $ref: "#/$defs/EpochAnchor";
+                    readonly description: "What was written — returned so an owner can see it without resolving their own room, and so an operator can compare it with what a member later reads.";
+                };
+                readonly versionId: {
+                    readonly type: "string";
+                    readonly description: "The `did:webvh` log entry the anchor rode. This is what makes the anchor *witnessed*: naming the entry lets anyone fetch it and check the witnesses' signature over it.";
+                };
+                readonly reconciled: {
+                    readonly type: "boolean";
+                    readonly description: "Whether the host's own listing reconciled with the `recordCount` it committed to, at the moment this was read.\n\n`false` is a host contradicting itself, and the anchor was still written — deliberately. An owner that refused to anchor a suspect room would leave it with no witnessed statement at all, which is the position the host benefits from. What is published is *what the host claimed*, and this member records that the owner had already caught it claiming something inconsistent.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+            readonly title: "Rooms Owner Anchor — response payload";
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly description: "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly EpochAnchor: {
+            readonly title: "EpochAnchor";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["epoch", "epochAuthenticator", "headVersion"];
+            readonly description: "What a room writes into its own witnessed log, so that a host serving a stale, forked or partial view of it becomes **evident rather than merely possible**.\n\n**Witnessed is the whole point.** Witnesses co-sign a `did:webvh` log entry, so a value that rides one is singular: the room cannot have told two members two different things about the same epoch without the log showing it. An anchor that did not ride a log entry would be a value the host could equally have made up, which is what every unanchored assertion in this family already is.\n\nIt goes in a **typed service entry** on the room's DID document, which is the only slot in a `did:webvh` log entry that carries an ecosystem-defined value today: `parameters` is a closed struct, `versionId` and `versionTime` are computed, and `proof` is the witnesses' signature over the rest — it secures the anchor and cannot be it.\n\n**Publishing one is not free.** A `did:webvh` update that supplies a document rotates the DID's update key and refreshes its pre-rotation commitments, so every anchor is a witnessed update *and* a rotation. That makes cadence an operational decision rather than only a freshness one: a room anchoring on every write would rotate its own DID's update key on every write.";
+            readonly properties: {
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this anchor describes.";
+                };
+                readonly epochAuthenticator: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "The MLS epoch authenticator for `epoch` — a value every member of the group derives independently and no host can compute. A member whose own authenticator differs from the anchored one is in a **forked group**, which is the attack this exists to make visible.";
+                };
+                readonly headVersion: {
+                    readonly $ref: "#/$defs/HeadVersion";
+                    readonly description: "The room's version watermark at the moment of anchoring, as the host reported it.";
+                };
+                readonly dataCommitment: {
+                    readonly $ref: "#/$defs/DataCommitment";
+                    readonly description: "The room's record-tree root at the same moment. OPTIONAL for the same reason it is on a read: a host that maintains no tree asserts none, and an owner cannot anchor what it was not given. Where it is present it is the only comparison in this family that needs neither a gossip channel rooms deliberately lack nor durable state in a member's agent — every member reads the same anchored root.";
+                };
+                readonly recordCount: {
+                    readonly $ref: "#/$defs/RecordCount";
+                    readonly description: "How many records the room held. Present with `dataCommitment` and absent without it: a root without the state it describes is not comparable to another root.";
+                };
+            };
+        };
+        readonly RecordCount: {
+            readonly title: "RecordCount";
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "How many records the room held when `DataCommitment` was computed — the number of leaves in that tree, tombstones included, since a tombstone is a record.\n\n**Why a root needs this.** Certificate Transparency's signed tree head is a root *and a tree size*; this family shipped the root alone, and the half that was dropped is the half that makes a listing checkable. A reader holding a **complete, unfiltered** listing cannot recompute the root — a leaf commits to a whole record and a listing returns a projection without the body — but it can count. A host that omits a record from a listing while committing to a tree that holds it now contradicts itself in the same response, with no second party and no anchor involved.\n\nA host can of course understate both together. That is the point rather than a hole: the omission stops being silence and becomes a **specific claim about how many records the room holds**, which any other member's view, or any writer's signed put acknowledgement, contradicts. Making an omission attributable is the whole of what this machinery buys; it never claimed to make one impossible.\n\n**It counts the room, never the page.** The same rule `DataCommitment` states, and the same trap: a count scoped to what was returned is one a host satisfies by construction. So this is only comparable against a listing read to the end with **no** `prefix` and **no** `sinceVersion` — a filtered listing legitimately holds fewer, and a reader that compares one against this has found a discrepancy it created itself.";
+        };
+        readonly DataCommitment: {
+            readonly title: "DataCommitment";
+            readonly $ref: "#/$defs/DigestMultibase";
+            readonly description: "The root of the room's record tree — a host's commitment to *which records the room holds*, as distinct from what any one of them says.\n\nA room's records are already signed and room-bound, so a host cannot forge, alter or relocate one. What it can do for free is stay silent: a listing that omits a record is indistinguishable from a room that never held it. This value is what makes that omission detectable, so it is only worth anything when the reader can compare it against a copy the host did not choose for them — one it gave another member, one it gave the same member earlier, or the witnessed anchor. A commitment read once, in isolation, proves nothing.\n\n**A root on its own is not comparable, and an earlier revision of this description said it was.** It claimed a host showing two members two different roots had been caught, which is false while a room can move between two reads: the host answers *there was a write*, and nothing contradicts it. Comparison needs the state each root describes, which is what `HeadVersion` names — and `RecordCount` is the other half of the same omission, since Certificate Transparency's signed tree head is a root *and a size* and this family shipped only the root. A reader that receives a `dataCommitment` **without** them can use it against a witnessed anchor, where the epoch pins the state, and **MUST NOT** compare it against another root.\n\n**The construction is normative**, because two hosts that compute different roots over the same room make every comparison meaningless:\n  1. Take every record the room holds — including tombstones, which are records — and order them by `key` using unsigned byte order.\n  2. Leaf: `SHA-256(0x00 || JCS(record))`, where the record is a `CommittedRecord` — that definition fixes the members exactly, and this step used to name a *projection* instead, which two implementations could read two ways — JCS is its RFC 8785 canonicalization, and `0x00` is RFC 6962's leaf-domain prefix.\n  3. Internal node: `SHA-256(0x01 || left || right)`.\n  4. A level with an odd number of nodes promotes the last one unchanged. It MUST NOT be duplicated: duplicating makes a tree of n leaves collide with one of n+1 whose last is repeated, so two different rooms commit to the same root.\n  5. A room holding no records commits to `SHA-256(\"\")`, a distinguished value rather than zeroes — a root of zeroes is what an uninitialised buffer looks like, and an empty room is a real state a host must be able to commit to honestly.\n\nThe leaf covers the whole record rather than its body, and that is deliberate: a host that could flip `status` from active to retracted, move `pinned`, or rewrite `author` on an `attributed` room would rewrite what the room means without touching a byte of ciphertext. The **plaintext is never involved** — on the sealed tiers the host holds ciphertext and commits to exactly what it stores.\n\nThe commitment is over the **whole room**, never over the page being returned. A page-scoped root is one a host satisfies by construction and could never fail.\n\nProving that a *particular* record sits under this root is a separate question, answered by `RecordTrace` on a single-record read. A commitment catches a host that equivocates; a trace binds one record to what the host committed to. Neither is the other, and a reader wanting completeness needs both plus a root it did not get from the host it is checking.";
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly description: "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+        };
+        readonly HeadVersion: {
+            readonly title: "HeadVersion";
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "The highest version among the records `DataCommitment` covers. `0` for a room that holds none.\n\n**Derived from the same set as the root, and not read from the room's own counter.** The two agree for any host that has never erased a record — versions are assigned strictly increasing and a retraction keeps its tombstone — but they are not interchangeable, because a root and a counter are *two reads*, and two reads are not a snapshot. A write landing between them yields a pair that is individually correct and jointly false: two members holding roots taken over different trees, labelled with one version. That reads as equivocation and is not, and a **false accusation discredits the mechanism rather than the host** — the worst outcome available here. Taken from the committed set, the version cannot disagree with the root it labels, whatever else is happening to the room.\n\nThe corollary is worth stating: a host that **erases** a record — as distinct from retracting it, which leaves a tombstone in the tree — moves the root without necessarily moving this value, and two members straddling that erasure would see one version over two roots. Erasure is a retention act with its own answer, and a family that exposes one owes this definition another look.\n\n**This is what makes two roots comparable at all**, and without it the comparison this family is built on cannot be performed. A room moves: every put, curate and retraction assigns a new version, so two roots taken at two moments differ legitimately and a reader learns nothing from the difference. Shown two different roots, a host that equivocated and a host that was merely written to are indistinguishable — the first can always answer *the room moved between your reads*, and nothing contradicts it.\n\nA version is assigned by exactly the mutations that change the tree — every put, curate and retraction takes the next one — so the highest of them names the **state** the root describes. Two roots carrying the same `headVersion` and differing is a host caught: there is no write to attribute the difference to. Two roots carrying different ones are simply two moments, and a reader should draw nothing from them.\n\nA host can lie about this number too, and it is then lying about the counter it also uses for optimistic concurrency (`expectedVersion`) and for incremental sync (`sinceVersion`) — so a member holding a signed acknowledgement of a write at version `V` contradicts any head below `V` directly.\n\n**Not a timestamp.** A time is host-asserted, unverifiable and useless for this: two roots a second apart are not evidence of anything, while two roots at one version are.";
+        };
+    };
+};
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export declare const RESPONSE_PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $ref: "#/$defs/Response";
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["roomId", "anchored", "versionId"];
+            readonly description: "Success response to rooms/owner/anchor. Type https://trusttasks.org/spec/rooms/owner/anchor/0.1#response.";
+            readonly properties: {
+                readonly roomId: {
+                    readonly type: "string";
+                };
+                readonly anchored: {
+                    readonly $ref: "#/$defs/EpochAnchor";
+                    readonly description: "What was written — returned so an owner can see it without resolving their own room, and so an operator can compare it with what a member later reads.";
+                };
+                readonly versionId: {
+                    readonly type: "string";
+                    readonly description: "The `did:webvh` log entry the anchor rode. This is what makes the anchor *witnessed*: naming the entry lets anyone fetch it and check the witnesses' signature over it.";
+                };
+                readonly reconciled: {
+                    readonly type: "boolean";
+                    readonly description: "Whether the host's own listing reconciled with the `recordCount` it committed to, at the moment this was read.\n\n`false` is a host contradicting itself, and the anchor was still written — deliberately. An owner that refused to anchor a suspect room would leave it with no witnessed statement at all, which is the position the host benefits from. What is published is *what the host claimed*, and this member records that the owner had already caught it claiming something inconsistent.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+            readonly title: "Rooms Owner Anchor — response payload";
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly description: "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly EpochAnchor: {
+            readonly title: "EpochAnchor";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["epoch", "epochAuthenticator", "headVersion"];
+            readonly description: "What a room writes into its own witnessed log, so that a host serving a stale, forked or partial view of it becomes **evident rather than merely possible**.\n\n**Witnessed is the whole point.** Witnesses co-sign a `did:webvh` log entry, so a value that rides one is singular: the room cannot have told two members two different things about the same epoch without the log showing it. An anchor that did not ride a log entry would be a value the host could equally have made up, which is what every unanchored assertion in this family already is.\n\nIt goes in a **typed service entry** on the room's DID document, which is the only slot in a `did:webvh` log entry that carries an ecosystem-defined value today: `parameters` is a closed struct, `versionId` and `versionTime` are computed, and `proof` is the witnesses' signature over the rest — it secures the anchor and cannot be it.\n\n**Publishing one is not free.** A `did:webvh` update that supplies a document rotates the DID's update key and refreshes its pre-rotation commitments, so every anchor is a witnessed update *and* a rotation. That makes cadence an operational decision rather than only a freshness one: a room anchoring on every write would rotate its own DID's update key on every write.";
+            readonly properties: {
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this anchor describes.";
+                };
+                readonly epochAuthenticator: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "The MLS epoch authenticator for `epoch` — a value every member of the group derives independently and no host can compute. A member whose own authenticator differs from the anchored one is in a **forked group**, which is the attack this exists to make visible.";
+                };
+                readonly headVersion: {
+                    readonly $ref: "#/$defs/HeadVersion";
+                    readonly description: "The room's version watermark at the moment of anchoring, as the host reported it.";
+                };
+                readonly dataCommitment: {
+                    readonly $ref: "#/$defs/DataCommitment";
+                    readonly description: "The room's record-tree root at the same moment. OPTIONAL for the same reason it is on a read: a host that maintains no tree asserts none, and an owner cannot anchor what it was not given. Where it is present it is the only comparison in this family that needs neither a gossip channel rooms deliberately lack nor durable state in a member's agent — every member reads the same anchored root.";
+                };
+                readonly recordCount: {
+                    readonly $ref: "#/$defs/RecordCount";
+                    readonly description: "How many records the room held. Present with `dataCommitment` and absent without it: a root without the state it describes is not comparable to another root.";
+                };
+            };
+        };
+        readonly RecordCount: {
+            readonly title: "RecordCount";
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "How many records the room held when `DataCommitment` was computed — the number of leaves in that tree, tombstones included, since a tombstone is a record.\n\n**Why a root needs this.** Certificate Transparency's signed tree head is a root *and a tree size*; this family shipped the root alone, and the half that was dropped is the half that makes a listing checkable. A reader holding a **complete, unfiltered** listing cannot recompute the root — a leaf commits to a whole record and a listing returns a projection without the body — but it can count. A host that omits a record from a listing while committing to a tree that holds it now contradicts itself in the same response, with no second party and no anchor involved.\n\nA host can of course understate both together. That is the point rather than a hole: the omission stops being silence and becomes a **specific claim about how many records the room holds**, which any other member's view, or any writer's signed put acknowledgement, contradicts. Making an omission attributable is the whole of what this machinery buys; it never claimed to make one impossible.\n\n**It counts the room, never the page.** The same rule `DataCommitment` states, and the same trap: a count scoped to what was returned is one a host satisfies by construction. So this is only comparable against a listing read to the end with **no** `prefix` and **no** `sinceVersion` — a filtered listing legitimately holds fewer, and a reader that compares one against this has found a discrepancy it created itself.";
+        };
+        readonly DataCommitment: {
+            readonly title: "DataCommitment";
+            readonly $ref: "#/$defs/DigestMultibase";
+            readonly description: "The root of the room's record tree — a host's commitment to *which records the room holds*, as distinct from what any one of them says.\n\nA room's records are already signed and room-bound, so a host cannot forge, alter or relocate one. What it can do for free is stay silent: a listing that omits a record is indistinguishable from a room that never held it. This value is what makes that omission detectable, so it is only worth anything when the reader can compare it against a copy the host did not choose for them — one it gave another member, one it gave the same member earlier, or the witnessed anchor. A commitment read once, in isolation, proves nothing.\n\n**A root on its own is not comparable, and an earlier revision of this description said it was.** It claimed a host showing two members two different roots had been caught, which is false while a room can move between two reads: the host answers *there was a write*, and nothing contradicts it. Comparison needs the state each root describes, which is what `HeadVersion` names — and `RecordCount` is the other half of the same omission, since Certificate Transparency's signed tree head is a root *and a size* and this family shipped only the root. A reader that receives a `dataCommitment` **without** them can use it against a witnessed anchor, where the epoch pins the state, and **MUST NOT** compare it against another root.\n\n**The construction is normative**, because two hosts that compute different roots over the same room make every comparison meaningless:\n  1. Take every record the room holds — including tombstones, which are records — and order them by `key` using unsigned byte order.\n  2. Leaf: `SHA-256(0x00 || JCS(record))`, where the record is a `CommittedRecord` — that definition fixes the members exactly, and this step used to name a *projection* instead, which two implementations could read two ways — JCS is its RFC 8785 canonicalization, and `0x00` is RFC 6962's leaf-domain prefix.\n  3. Internal node: `SHA-256(0x01 || left || right)`.\n  4. A level with an odd number of nodes promotes the last one unchanged. It MUST NOT be duplicated: duplicating makes a tree of n leaves collide with one of n+1 whose last is repeated, so two different rooms commit to the same root.\n  5. A room holding no records commits to `SHA-256(\"\")`, a distinguished value rather than zeroes — a root of zeroes is what an uninitialised buffer looks like, and an empty room is a real state a host must be able to commit to honestly.\n\nThe leaf covers the whole record rather than its body, and that is deliberate: a host that could flip `status` from active to retracted, move `pinned`, or rewrite `author` on an `attributed` room would rewrite what the room means without touching a byte of ciphertext. The **plaintext is never involved** — on the sealed tiers the host holds ciphertext and commits to exactly what it stores.\n\nThe commitment is over the **whole room**, never over the page being returned. A page-scoped root is one a host satisfies by construction and could never fail.\n\nProving that a *particular* record sits under this root is a separate question, answered by `RecordTrace` on a single-record read. A commitment catches a host that equivocates; a trace binds one record to what the host committed to. Neither is the other, and a reader wanting completeness needs both plus a root it did not get from the host it is checking.";
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly description: "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+        };
+        readonly HeadVersion: {
+            readonly title: "HeadVersion";
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "The highest version among the records `DataCommitment` covers. `0` for a room that holds none.\n\n**Derived from the same set as the root, and not read from the room's own counter.** The two agree for any host that has never erased a record — versions are assigned strictly increasing and a retraction keeps its tombstone — but they are not interchangeable, because a root and a counter are *two reads*, and two reads are not a snapshot. A write landing between them yields a pair that is individually correct and jointly false: two members holding roots taken over different trees, labelled with one version. That reads as equivocation and is not, and a **false accusation discredits the mechanism rather than the host** — the worst outcome available here. Taken from the committed set, the version cannot disagree with the root it labels, whatever else is happening to the room.\n\nThe corollary is worth stating: a host that **erases** a record — as distinct from retracting it, which leaves a tombstone in the tree — moves the root without necessarily moving this value, and two members straddling that erasure would see one version over two roots. Erasure is a retention act with its own answer, and a family that exposes one owes this definition another look.\n\n**This is what makes two roots comparable at all**, and without it the comparison this family is built on cannot be performed. A room moves: every put, curate and retraction assigns a new version, so two roots taken at two moments differ legitimately and a reader learns nothing from the difference. Shown two different roots, a host that equivocated and a host that was merely written to are indistinguishable — the first can always answer *the room moved between your reads*, and nothing contradicts it.\n\nA version is assigned by exactly the mutations that change the tree — every put, curate and retraction takes the next one — so the highest of them names the **state** the root describes. Two roots carrying the same `headVersion` and differing is a host caught: there is no write to attribute the difference to. Two roots carrying different ones are simply two moments, and a reader should draw nothing from them.\n\nA host can lie about this number too, and it is then lying about the counter it also uses for optimistic concurrency (`expectedVersion`) and for incremental sync (`sinceVersion`) — so a member holding a signed acknowledgement of a write at version `V` contradicts any head below `V` directly.\n\n**Not a timestamp.** A time is host-asserted, unverifiable and useless for this: two roots a second apart are not evidence of anything, while two roots at one version are.";
+        };
+    };
+};
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export declare const SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/rooms/owner/anchor/0.1";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $id: "https://trusttasks.org/spec/rooms/owner/anchor/0.1";
+        readonly title: "Rooms Owner Anchor — payload";
+        readonly description: "TODO: what the request payload of rooms/owner/anchor carries. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["roomId", "host", "signingKeyId"];
+        readonly properties: {
+            readonly roomId: {
+                readonly type: "string";
+                readonly description: "The room to anchor. The recipient MUST hold its group state and MUST be able to update its DID.";
+            };
+            readonly host: {
+                readonly type: "string";
+                readonly description: "The host to read the room's head from, as a DID.\n\nThe owner holds **one** of the three values it is about to publish. `rooms/epoch/mint`'s response is `{roomId, epoch}` — no watermark, and no reason there should be one: minting acts on the epoch, while the watermark and the commitment are facts about the room's *records*, which live at the host. So an anchor is assembled from a read, and this names where.";
+            };
+            readonly signingKeyId: {
+                readonly type: "string";
+                readonly description: "The room's signing key, named rather than looked up: nothing maps a DID to its key, and a wrong key fails to verify against the room's own document at first use.";
+            };
+            readonly ext: {
+                readonly $ref: "#/$defs/Ext";
+                readonly description: "Ecosystem-defined extension members per SPEC.md §4.5.1.";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["roomId", "anchored", "versionId"];
+                readonly description: "Success response to rooms/owner/anchor. Type https://trusttasks.org/spec/rooms/owner/anchor/0.1#response.";
+                readonly properties: {
+                    readonly roomId: {
+                        readonly type: "string";
+                    };
+                    readonly anchored: {
+                        readonly $ref: "#/$defs/EpochAnchor";
+                        readonly description: "What was written — returned so an owner can see it without resolving their own room, and so an operator can compare it with what a member later reads.";
+                    };
+                    readonly versionId: {
+                        readonly type: "string";
+                        readonly description: "The `did:webvh` log entry the anchor rode. This is what makes the anchor *witnessed*: naming the entry lets anyone fetch it and check the witnesses' signature over it.";
+                    };
+                    readonly reconciled: {
+                        readonly type: "boolean";
+                        readonly description: "Whether the host's own listing reconciled with the `recordCount` it committed to, at the moment this was read.\n\n`false` is a host contradicting itself, and the anchor was still written — deliberately. An owner that refused to anchor a suspect room would leave it with no witnessed statement at all, which is the position the host benefits from. What is published is *what the host claimed*, and this member records that the owner had already caught it claiming something inconsistent.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+                readonly title: "Rooms Owner Anchor — response payload";
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly description: "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly EpochAnchor: {
+                readonly title: "EpochAnchor";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["epoch", "epochAuthenticator", "headVersion"];
+                readonly description: "What a room writes into its own witnessed log, so that a host serving a stale, forked or partial view of it becomes **evident rather than merely possible**.\n\n**Witnessed is the whole point.** Witnesses co-sign a `did:webvh` log entry, so a value that rides one is singular: the room cannot have told two members two different things about the same epoch without the log showing it. An anchor that did not ride a log entry would be a value the host could equally have made up, which is what every unanchored assertion in this family already is.\n\nIt goes in a **typed service entry** on the room's DID document, which is the only slot in a `did:webvh` log entry that carries an ecosystem-defined value today: `parameters` is a closed struct, `versionId` and `versionTime` are computed, and `proof` is the witnesses' signature over the rest — it secures the anchor and cannot be it.\n\n**Publishing one is not free.** A `did:webvh` update that supplies a document rotates the DID's update key and refreshes its pre-rotation commitments, so every anchor is a witnessed update *and* a rotation. That makes cadence an operational decision rather than only a freshness one: a room anchoring on every write would rotate its own DID's update key on every write.";
+                readonly properties: {
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this anchor describes.";
+                    };
+                    readonly epochAuthenticator: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "The MLS epoch authenticator for `epoch` — a value every member of the group derives independently and no host can compute. A member whose own authenticator differs from the anchored one is in a **forked group**, which is the attack this exists to make visible.";
+                    };
+                    readonly headVersion: {
+                        readonly $ref: "#/$defs/HeadVersion";
+                        readonly description: "The room's version watermark at the moment of anchoring, as the host reported it.";
+                    };
+                    readonly dataCommitment: {
+                        readonly $ref: "#/$defs/DataCommitment";
+                        readonly description: "The room's record-tree root at the same moment. OPTIONAL for the same reason it is on a read: a host that maintains no tree asserts none, and an owner cannot anchor what it was not given. Where it is present it is the only comparison in this family that needs neither a gossip channel rooms deliberately lack nor durable state in a member's agent — every member reads the same anchored root.";
+                    };
+                    readonly recordCount: {
+                        readonly $ref: "#/$defs/RecordCount";
+                        readonly description: "How many records the room held. Present with `dataCommitment` and absent without it: a root without the state it describes is not comparable to another root.";
+                    };
+                };
+            };
+            readonly RecordCount: {
+                readonly title: "RecordCount";
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "How many records the room held when `DataCommitment` was computed — the number of leaves in that tree, tombstones included, since a tombstone is a record.\n\n**Why a root needs this.** Certificate Transparency's signed tree head is a root *and a tree size*; this family shipped the root alone, and the half that was dropped is the half that makes a listing checkable. A reader holding a **complete, unfiltered** listing cannot recompute the root — a leaf commits to a whole record and a listing returns a projection without the body — but it can count. A host that omits a record from a listing while committing to a tree that holds it now contradicts itself in the same response, with no second party and no anchor involved.\n\nA host can of course understate both together. That is the point rather than a hole: the omission stops being silence and becomes a **specific claim about how many records the room holds**, which any other member's view, or any writer's signed put acknowledgement, contradicts. Making an omission attributable is the whole of what this machinery buys; it never claimed to make one impossible.\n\n**It counts the room, never the page.** The same rule `DataCommitment` states, and the same trap: a count scoped to what was returned is one a host satisfies by construction. So this is only comparable against a listing read to the end with **no** `prefix` and **no** `sinceVersion` — a filtered listing legitimately holds fewer, and a reader that compares one against this has found a discrepancy it created itself.";
+            };
+            readonly DataCommitment: {
+                readonly title: "DataCommitment";
+                readonly $ref: "#/$defs/DigestMultibase";
+                readonly description: "The root of the room's record tree — a host's commitment to *which records the room holds*, as distinct from what any one of them says.\n\nA room's records are already signed and room-bound, so a host cannot forge, alter or relocate one. What it can do for free is stay silent: a listing that omits a record is indistinguishable from a room that never held it. This value is what makes that omission detectable, so it is only worth anything when the reader can compare it against a copy the host did not choose for them — one it gave another member, one it gave the same member earlier, or the witnessed anchor. A commitment read once, in isolation, proves nothing.\n\n**A root on its own is not comparable, and an earlier revision of this description said it was.** It claimed a host showing two members two different roots had been caught, which is false while a room can move between two reads: the host answers *there was a write*, and nothing contradicts it. Comparison needs the state each root describes, which is what `HeadVersion` names — and `RecordCount` is the other half of the same omission, since Certificate Transparency's signed tree head is a root *and a size* and this family shipped only the root. A reader that receives a `dataCommitment` **without** them can use it against a witnessed anchor, where the epoch pins the state, and **MUST NOT** compare it against another root.\n\n**The construction is normative**, because two hosts that compute different roots over the same room make every comparison meaningless:\n  1. Take every record the room holds — including tombstones, which are records — and order them by `key` using unsigned byte order.\n  2. Leaf: `SHA-256(0x00 || JCS(record))`, where the record is a `CommittedRecord` — that definition fixes the members exactly, and this step used to name a *projection* instead, which two implementations could read two ways — JCS is its RFC 8785 canonicalization, and `0x00` is RFC 6962's leaf-domain prefix.\n  3. Internal node: `SHA-256(0x01 || left || right)`.\n  4. A level with an odd number of nodes promotes the last one unchanged. It MUST NOT be duplicated: duplicating makes a tree of n leaves collide with one of n+1 whose last is repeated, so two different rooms commit to the same root.\n  5. A room holding no records commits to `SHA-256(\"\")`, a distinguished value rather than zeroes — a root of zeroes is what an uninitialised buffer looks like, and an empty room is a real state a host must be able to commit to honestly.\n\nThe leaf covers the whole record rather than its body, and that is deliberate: a host that could flip `status` from active to retracted, move `pinned`, or rewrite `author` on an `attributed` room would rewrite what the room means without touching a byte of ciphertext. The **plaintext is never involved** — on the sealed tiers the host holds ciphertext and commits to exactly what it stores.\n\nThe commitment is over the **whole room**, never over the page being returned. A page-scoped root is one a host satisfies by construction and could never fail.\n\nProving that a *particular* record sits under this root is a separate question, answered by `RecordTrace` on a single-record read. A commitment catches a host that equivocates; a trace binds one record to what the host committed to. Neither is the other, and a reader wanting completeness needs both plus a root it did not get from the host it is checking.";
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly description: "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+            readonly HeadVersion: {
+                readonly title: "HeadVersion";
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "The highest version among the records `DataCommitment` covers. `0` for a room that holds none.\n\n**Derived from the same set as the root, and not read from the room's own counter.** The two agree for any host that has never erased a record — versions are assigned strictly increasing and a retraction keeps its tombstone — but they are not interchangeable, because a root and a counter are *two reads*, and two reads are not a snapshot. A write landing between them yields a pair that is individually correct and jointly false: two members holding roots taken over different trees, labelled with one version. That reads as equivocation and is not, and a **false accusation discredits the mechanism rather than the host** — the worst outcome available here. Taken from the committed set, the version cannot disagree with the root it labels, whatever else is happening to the room.\n\nThe corollary is worth stating: a host that **erases** a record — as distinct from retracting it, which leaves a tombstone in the tree — moves the root without necessarily moving this value, and two members straddling that erasure would see one version over two roots. Erasure is a retention act with its own answer, and a family that exposes one owes this definition another look.\n\n**This is what makes two roots comparable at all**, and without it the comparison this family is built on cannot be performed. A room moves: every put, curate and retraction assigns a new version, so two roots taken at two moments differ legitimately and a reader learns nothing from the difference. Shown two different roots, a host that equivocated and a host that was merely written to are indistinguishable — the first can always answer *the room moved between your reads*, and nothing contradicts it.\n\nA version is assigned by exactly the mutations that change the tree — every put, curate and retraction takes the next one — so the highest of them names the **state** the root describes. Two roots carrying the same `headVersion` and differing is a host caught: there is no write to attribute the difference to. Two roots carrying different ones are simply two moments, and a reader should draw nothing from them.\n\nA host can lie about this number too, and it is then lying about the counter it also uses for optimistic concurrency (`expectedVersion`) and for incremental sync (`sinceVersion`) — so a member holding a signed acknowledgement of a write at version `V` contradicts any head below `V` directly.\n\n**Not a timestamp.** A time is host-asserted, unverifiable and useless for this: two roots a second apart are not evidence of anything, while two roots at one version are.";
+            };
+        };
+    };
+};
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export declare const RESPONSE_SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/rooms/owner/anchor/0.1#response";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $ref: "#/$defs/Response";
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["roomId", "anchored", "versionId"];
+                readonly description: "Success response to rooms/owner/anchor. Type https://trusttasks.org/spec/rooms/owner/anchor/0.1#response.";
+                readonly properties: {
+                    readonly roomId: {
+                        readonly type: "string";
+                    };
+                    readonly anchored: {
+                        readonly $ref: "#/$defs/EpochAnchor";
+                        readonly description: "What was written — returned so an owner can see it without resolving their own room, and so an operator can compare it with what a member later reads.";
+                    };
+                    readonly versionId: {
+                        readonly type: "string";
+                        readonly description: "The `did:webvh` log entry the anchor rode. This is what makes the anchor *witnessed*: naming the entry lets anyone fetch it and check the witnesses' signature over it.";
+                    };
+                    readonly reconciled: {
+                        readonly type: "boolean";
+                        readonly description: "Whether the host's own listing reconciled with the `recordCount` it committed to, at the moment this was read.\n\n`false` is a host contradicting itself, and the anchor was still written — deliberately. An owner that refused to anchor a suspect room would leave it with no witnessed statement at all, which is the position the host benefits from. What is published is *what the host claimed*, and this member records that the owner had already caught it claiming something inconsistent.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+                readonly title: "Rooms Owner Anchor — response payload";
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly description: "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly EpochAnchor: {
+                readonly title: "EpochAnchor";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["epoch", "epochAuthenticator", "headVersion"];
+                readonly description: "What a room writes into its own witnessed log, so that a host serving a stale, forked or partial view of it becomes **evident rather than merely possible**.\n\n**Witnessed is the whole point.** Witnesses co-sign a `did:webvh` log entry, so a value that rides one is singular: the room cannot have told two members two different things about the same epoch without the log showing it. An anchor that did not ride a log entry would be a value the host could equally have made up, which is what every unanchored assertion in this family already is.\n\nIt goes in a **typed service entry** on the room's DID document, which is the only slot in a `did:webvh` log entry that carries an ecosystem-defined value today: `parameters` is a closed struct, `versionId` and `versionTime` are computed, and `proof` is the witnesses' signature over the rest — it secures the anchor and cannot be it.\n\n**Publishing one is not free.** A `did:webvh` update that supplies a document rotates the DID's update key and refreshes its pre-rotation commitments, so every anchor is a witnessed update *and* a rotation. That makes cadence an operational decision rather than only a freshness one: a room anchoring on every write would rotate its own DID's update key on every write.";
+                readonly properties: {
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this anchor describes.";
+                    };
+                    readonly epochAuthenticator: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "The MLS epoch authenticator for `epoch` — a value every member of the group derives independently and no host can compute. A member whose own authenticator differs from the anchored one is in a **forked group**, which is the attack this exists to make visible.";
+                    };
+                    readonly headVersion: {
+                        readonly $ref: "#/$defs/HeadVersion";
+                        readonly description: "The room's version watermark at the moment of anchoring, as the host reported it.";
+                    };
+                    readonly dataCommitment: {
+                        readonly $ref: "#/$defs/DataCommitment";
+                        readonly description: "The room's record-tree root at the same moment. OPTIONAL for the same reason it is on a read: a host that maintains no tree asserts none, and an owner cannot anchor what it was not given. Where it is present it is the only comparison in this family that needs neither a gossip channel rooms deliberately lack nor durable state in a member's agent — every member reads the same anchored root.";
+                    };
+                    readonly recordCount: {
+                        readonly $ref: "#/$defs/RecordCount";
+                        readonly description: "How many records the room held. Present with `dataCommitment` and absent without it: a root without the state it describes is not comparable to another root.";
+                    };
+                };
+            };
+            readonly RecordCount: {
+                readonly title: "RecordCount";
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "How many records the room held when `DataCommitment` was computed — the number of leaves in that tree, tombstones included, since a tombstone is a record.\n\n**Why a root needs this.** Certificate Transparency's signed tree head is a root *and a tree size*; this family shipped the root alone, and the half that was dropped is the half that makes a listing checkable. A reader holding a **complete, unfiltered** listing cannot recompute the root — a leaf commits to a whole record and a listing returns a projection without the body — but it can count. A host that omits a record from a listing while committing to a tree that holds it now contradicts itself in the same response, with no second party and no anchor involved.\n\nA host can of course understate both together. That is the point rather than a hole: the omission stops being silence and becomes a **specific claim about how many records the room holds**, which any other member's view, or any writer's signed put acknowledgement, contradicts. Making an omission attributable is the whole of what this machinery buys; it never claimed to make one impossible.\n\n**It counts the room, never the page.** The same rule `DataCommitment` states, and the same trap: a count scoped to what was returned is one a host satisfies by construction. So this is only comparable against a listing read to the end with **no** `prefix` and **no** `sinceVersion` — a filtered listing legitimately holds fewer, and a reader that compares one against this has found a discrepancy it created itself.";
+            };
+            readonly DataCommitment: {
+                readonly title: "DataCommitment";
+                readonly $ref: "#/$defs/DigestMultibase";
+                readonly description: "The root of the room's record tree — a host's commitment to *which records the room holds*, as distinct from what any one of them says.\n\nA room's records are already signed and room-bound, so a host cannot forge, alter or relocate one. What it can do for free is stay silent: a listing that omits a record is indistinguishable from a room that never held it. This value is what makes that omission detectable, so it is only worth anything when the reader can compare it against a copy the host did not choose for them — one it gave another member, one it gave the same member earlier, or the witnessed anchor. A commitment read once, in isolation, proves nothing.\n\n**A root on its own is not comparable, and an earlier revision of this description said it was.** It claimed a host showing two members two different roots had been caught, which is false while a room can move between two reads: the host answers *there was a write*, and nothing contradicts it. Comparison needs the state each root describes, which is what `HeadVersion` names — and `RecordCount` is the other half of the same omission, since Certificate Transparency's signed tree head is a root *and a size* and this family shipped only the root. A reader that receives a `dataCommitment` **without** them can use it against a witnessed anchor, where the epoch pins the state, and **MUST NOT** compare it against another root.\n\n**The construction is normative**, because two hosts that compute different roots over the same room make every comparison meaningless:\n  1. Take every record the room holds — including tombstones, which are records — and order them by `key` using unsigned byte order.\n  2. Leaf: `SHA-256(0x00 || JCS(record))`, where the record is a `CommittedRecord` — that definition fixes the members exactly, and this step used to name a *projection* instead, which two implementations could read two ways — JCS is its RFC 8785 canonicalization, and `0x00` is RFC 6962's leaf-domain prefix.\n  3. Internal node: `SHA-256(0x01 || left || right)`.\n  4. A level with an odd number of nodes promotes the last one unchanged. It MUST NOT be duplicated: duplicating makes a tree of n leaves collide with one of n+1 whose last is repeated, so two different rooms commit to the same root.\n  5. A room holding no records commits to `SHA-256(\"\")`, a distinguished value rather than zeroes — a root of zeroes is what an uninitialised buffer looks like, and an empty room is a real state a host must be able to commit to honestly.\n\nThe leaf covers the whole record rather than its body, and that is deliberate: a host that could flip `status` from active to retracted, move `pinned`, or rewrite `author` on an `attributed` room would rewrite what the room means without touching a byte of ciphertext. The **plaintext is never involved** — on the sealed tiers the host holds ciphertext and commits to exactly what it stores.\n\nThe commitment is over the **whole room**, never over the page being returned. A page-scoped root is one a host satisfies by construction and could never fail.\n\nProving that a *particular* record sits under this root is a separate question, answered by `RecordTrace` on a single-record read. A commitment catches a host that equivocates; a trace binds one record to what the host committed to. Neither is the other, and a reader wanting completeness needs both plus a root it did not get from the host it is checking.";
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly description: "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+            readonly HeadVersion: {
+                readonly title: "HeadVersion";
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "The highest version among the records `DataCommitment` covers. `0` for a room that holds none.\n\n**Derived from the same set as the root, and not read from the room's own counter.** The two agree for any host that has never erased a record — versions are assigned strictly increasing and a retraction keeps its tombstone — but they are not interchangeable, because a root and a counter are *two reads*, and two reads are not a snapshot. A write landing between them yields a pair that is individually correct and jointly false: two members holding roots taken over different trees, labelled with one version. That reads as equivocation and is not, and a **false accusation discredits the mechanism rather than the host** — the worst outcome available here. Taken from the committed set, the version cannot disagree with the root it labels, whatever else is happening to the room.\n\nThe corollary is worth stating: a host that **erases** a record — as distinct from retracting it, which leaves a tombstone in the tree — moves the root without necessarily moving this value, and two members straddling that erasure would see one version over two roots. Erasure is a retention act with its own answer, and a family that exposes one owes this definition another look.\n\n**This is what makes two roots comparable at all**, and without it the comparison this family is built on cannot be performed. A room moves: every put, curate and retraction assigns a new version, so two roots taken at two moments differ legitimately and a reader learns nothing from the difference. Shown two different roots, a host that equivocated and a host that was merely written to are indistinguishable — the first can always answer *the room moved between your reads*, and nothing contradicts it.\n\nA version is assigned by exactly the mutations that change the tree — every put, curate and retraction takes the next one — so the highest of them names the **state** the root describes. Two roots carrying the same `headVersion` and differing is a host caught: there is no write to attribute the difference to. Two roots carrying different ones are simply two moments, and a reader should draw nothing from them.\n\nA host can lie about this number too, and it is then lying about the counter it also uses for optimistic concurrency (`expectedVersion`) and for incremental sync (`sinceVersion`) — so a member holding a signed acknowledgement of a write at version `V` contradicts any head below `V` directly.\n\n**Not a timestamp.** A time is host-asserted, unverifiable and useless for this: two roots a second apart are not evidence of anything, while two roots at one version are.";
+            };
+        };
+    };
+};
+//# sourceMappingURL=payload.d.ts.map

package/dist/rooms/owner/anchor/0.1/payload.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/rooms/owner/anchor/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,eAAe,EAAE,WAAW,EAAE,GAAG,EAAE,WAAW,EAAE,WAAW,EAAE,MAAM,mCAAmC,CAAC;AAGrI;;GAEG;AACH,MAAM,WAAW,uBAAuB;IACtC;;OAEG;IACH,MAAM,EAAE,MAAM,CAAC;IACf;;;;OAIG;IACH,IAAI,EAAE,MAAM,CAAC;IACb;;OAEG;IACH,YAAY,EAAE,MAAM,CAAC;IACrB;;OAEG;IACH,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,+BAA+B;IAC9C,MAAM,EAAE,MAAM,CAAC;IACf;;OAEG;IACH,QAAQ,EAAE,WAAW,CAAC;IACtB;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB;;;;OAIG;IACH,UAAU,CAAC,EAAE,OAAO,CAAC;IACrB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,kHAAkH;AAClH,YAAY,EAAE,cAAc,EAAE,eAAe,EAAE,WAAW,EAAE,GAAG,EAAE,WAAW,EAAE,WAAW,EAAE,CAAC;AAE5F,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,oDAA6D,CAAC;AAEtF,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,uBAAuB,CAAC;AAE9C,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,6DAAsE,CAAC;AAExG,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,+BAA+B,CAAC;AAEvD;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuIjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4G1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOhB,CAAC"}