@openvtc/trust-tasks 0.23.7 → 0.23.9

package/dist/rooms/records/put/0.2/payload.d.ts

@@ -0,0 +1,679 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/records/put/0.2/payload.schema.json
+ */
+import type { AuthorityPresentation, BlobRef, DigestMultibase, Ext, SealedRecord } from "../../../../_shared/components.js";
+/**
+ * A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 adds `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it.
+ */
+export interface RoomsRecordsPutPayload {
+    /**
+     * The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.
+     */
+    roomId: string;
+    /**
+     * The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.
+     */
+    key: string;
+    /**
+     * Must confer the `write` action at this room's scope.
+     */
+    presentation: AuthorityPresentation;
+    /**
+     * Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.
+     */
+    expectedVersion?: number;
+    /**
+     * REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.
+     */
+    sealed?: SealedRecord;
+    /**
+     * REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`.
+     */
+    cleartext?: {
+        title?: string;
+        description?: string;
+        body: string;
+        /**
+         * @maxItems 32
+         */
+        tags?: string[];
+    };
+    /**
+     * The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.
+     *
+     * @minItems 1
+     * @maxItems 1
+     */
+    blobs?: [BlobRef];
+    /**
+     * Ecosystem-defined extension members per SPEC.md §4.5.1.
+     */
+    ext?: Ext;
+}
+/**
+ * Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.2#response.
+ */
+export interface RoomsRecordsPutResponsePayload {
+    /**
+     * The stored record's key.
+     */
+    key: string;
+    /**
+     * The version assigned, monotonic per room.
+     */
+    version: number;
+    /**
+     * The epoch the record was stored under.
+     */
+    epoch?: number;
+    ext?: Ext;
+}
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AuthorityPresentation, BlobRef, DigestMultibase, Ext, SealedRecord };
+/** Trust Task type URI. */
+export declare const TYPE_URI: "https://trusttasks.org/spec/rooms/records/put/0.2";
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsRecordsPutPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/rooms/records/put/0.2#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsRecordsPutResponsePayload;
+/**
+ * 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/records/put/0.2";
+    readonly title: "Rooms Records Put — payload";
+    readonly description: "A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 adds `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["roomId", "key", "presentation"];
+    readonly properties: {
+        readonly roomId: {
+            readonly type: "string";
+            readonly description: "The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.";
+        };
+        readonly key: {
+            readonly type: "string";
+            readonly maxLength: 512;
+            readonly description: "The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.";
+        };
+        readonly presentation: {
+            readonly $ref: "#/$defs/AuthorityPresentation";
+            readonly description: "Must confer the `write` action at this room's scope.";
+        };
+        readonly expectedVersion: {
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.";
+        };
+        readonly sealed: {
+            readonly $ref: "#/$defs/SealedRecord";
+            readonly description: "REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.";
+        };
+        readonly cleartext: {
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["body"];
+            readonly description: "REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`.";
+            readonly properties: {
+                readonly title: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                };
+                readonly description: {
+                    readonly type: "string";
+                    readonly maxLength: 2048;
+                };
+                readonly body: {
+                    readonly type: "string";
+                    readonly maxLength: 1048576;
+                };
+                readonly tags: {
+                    readonly type: "array";
+                    readonly items: {
+                        readonly type: "string";
+                        readonly maxLength: 64;
+                    };
+                    readonly maxItems: 32;
+                };
+            };
+        };
+        readonly blobs: {
+            readonly type: "array";
+            readonly minItems: 1;
+            readonly maxItems: 1;
+            readonly uniqueItems: true;
+            readonly items: {
+                readonly $ref: "#/$defs/BlobRef";
+            };
+            readonly description: "The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.";
+        };
+        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 title: "Rooms Records Put — response payload";
+            readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.2#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["key", "version"];
+            readonly properties: {
+                readonly key: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                    readonly description: "The stored record's key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version assigned, monotonic per room.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The epoch the record was stored under.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        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 BlobRef: {
+            readonly title: "BlobRef";
+            readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+            readonly $ref: "#/$defs/DigestMultibase";
+        };
+        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 SealedRecord: {
+            readonly title: "SealedRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["ciphertext", "nonce", "epoch"];
+            readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+            readonly properties: {
+                readonly ciphertext: {
+                    readonly type: "string";
+                    readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it.";
+                };
+                readonly nonce: {
+                    readonly type: "string";
+                    readonly description: "AEAD nonce, base64url.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                };
+            };
+        };
+        readonly AuthorityPresentation: {
+            readonly title: "AuthorityPresentation";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["membership", "authority"];
+            readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.";
+            readonly properties: {
+                readonly membership: {
+                    readonly type: "string";
+                    readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                };
+                readonly authority: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                    readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                };
+                readonly subjectBinding: {
+                    readonly type: "string";
+                    readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                };
+            };
+        };
+    };
+};
+/** 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 title: "Rooms Records Put — response payload";
+            readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.2#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["key", "version"];
+            readonly properties: {
+                readonly key: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                    readonly description: "The stored record's key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version assigned, monotonic per room.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The epoch the record was stored under.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        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 BlobRef: {
+            readonly title: "BlobRef";
+            readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+            readonly $ref: "#/$defs/DigestMultibase";
+        };
+        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 SealedRecord: {
+            readonly title: "SealedRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["ciphertext", "nonce", "epoch"];
+            readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+            readonly properties: {
+                readonly ciphertext: {
+                    readonly type: "string";
+                    readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it.";
+                };
+                readonly nonce: {
+                    readonly type: "string";
+                    readonly description: "AEAD nonce, base64url.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                };
+            };
+        };
+        readonly AuthorityPresentation: {
+            readonly title: "AuthorityPresentation";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["membership", "authority"];
+            readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.";
+            readonly properties: {
+                readonly membership: {
+                    readonly type: "string";
+                    readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                };
+                readonly authority: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                    readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                };
+                readonly subjectBinding: {
+                    readonly type: "string";
+                    readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                };
+            };
+        };
+    };
+};
+/**
+ * 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/records/put/0.2";
+    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/records/put/0.2";
+        readonly title: "Rooms Records Put — payload";
+        readonly description: "A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 adds `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["roomId", "key", "presentation"];
+        readonly properties: {
+            readonly roomId: {
+                readonly type: "string";
+                readonly description: "The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.";
+            };
+            readonly key: {
+                readonly type: "string";
+                readonly maxLength: 512;
+                readonly description: "The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.";
+            };
+            readonly presentation: {
+                readonly $ref: "#/$defs/AuthorityPresentation";
+                readonly description: "Must confer the `write` action at this room's scope.";
+            };
+            readonly expectedVersion: {
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.";
+            };
+            readonly sealed: {
+                readonly $ref: "#/$defs/SealedRecord";
+                readonly description: "REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.";
+            };
+            readonly cleartext: {
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["body"];
+                readonly description: "REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`.";
+                readonly properties: {
+                    readonly title: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                    };
+                    readonly description: {
+                        readonly type: "string";
+                        readonly maxLength: 2048;
+                    };
+                    readonly body: {
+                        readonly type: "string";
+                        readonly maxLength: 1048576;
+                    };
+                    readonly tags: {
+                        readonly type: "array";
+                        readonly items: {
+                            readonly type: "string";
+                            readonly maxLength: 64;
+                        };
+                        readonly maxItems: 32;
+                    };
+                };
+            };
+            readonly blobs: {
+                readonly type: "array";
+                readonly minItems: 1;
+                readonly maxItems: 1;
+                readonly uniqueItems: true;
+                readonly items: {
+                    readonly $ref: "#/$defs/BlobRef";
+                };
+                readonly description: "The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.";
+            };
+            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 title: "Rooms Records Put — response payload";
+                readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.2#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["key", "version"];
+                readonly properties: {
+                    readonly key: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                        readonly description: "The stored record's key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version assigned, monotonic per room.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The epoch the record was stored under.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            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 BlobRef: {
+                readonly title: "BlobRef";
+                readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+                readonly $ref: "#/$defs/DigestMultibase";
+            };
+            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 SealedRecord: {
+                readonly title: "SealedRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["ciphertext", "nonce", "epoch"];
+                readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+                readonly properties: {
+                    readonly ciphertext: {
+                        readonly type: "string";
+                        readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it.";
+                    };
+                    readonly nonce: {
+                        readonly type: "string";
+                        readonly description: "AEAD nonce, base64url.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                    };
+                };
+            };
+            readonly AuthorityPresentation: {
+                readonly title: "AuthorityPresentation";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["membership", "authority"];
+                readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.";
+                readonly properties: {
+                    readonly membership: {
+                        readonly type: "string";
+                        readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                    };
+                    readonly authority: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly items: {
+                            readonly type: "string";
+                        };
+                        readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                    };
+                    readonly subjectBinding: {
+                        readonly type: "string";
+                        readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                    };
+                };
+            };
+        };
+    };
+};
+/**
+ * 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/records/put/0.2#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 title: "Rooms Records Put — response payload";
+                readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.2#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["key", "version"];
+                readonly properties: {
+                    readonly key: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                        readonly description: "The stored record's key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version assigned, monotonic per room.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The epoch the record was stored under.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            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 BlobRef: {
+                readonly title: "BlobRef";
+                readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+                readonly $ref: "#/$defs/DigestMultibase";
+            };
+            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 SealedRecord: {
+                readonly title: "SealedRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["ciphertext", "nonce", "epoch"];
+                readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+                readonly properties: {
+                    readonly ciphertext: {
+                        readonly type: "string";
+                        readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it.";
+                    };
+                    readonly nonce: {
+                        readonly type: "string";
+                        readonly description: "AEAD nonce, base64url.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                    };
+                };
+            };
+            readonly AuthorityPresentation: {
+                readonly title: "AuthorityPresentation";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["membership", "authority"];
+                readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.";
+                readonly properties: {
+                    readonly membership: {
+                        readonly type: "string";
+                        readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                    };
+                    readonly authority: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly items: {
+                            readonly type: "string";
+                        };
+                        readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                    };
+                    readonly subjectBinding: {
+                        readonly type: "string";
+                        readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                    };
+                };
+            };
+        };
+    };
+};
+//# sourceMappingURL=payload.d.ts.map