@openvtc/trust-tasks 0.26.3 → 0.26.4

package/src/rooms/blobs/upload/begin/0.2/payload.ts

@@ -0,0 +1,731 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/blobs/upload/begin/0.2/payload.schema.json
+ */
+
+import type { AuthorityPresentation, BlobManifest, ChunkCount, ChunkIndex, ChunkManifest, ChunkSize, DigestMultibase, ExpectedSizeBytes, ExpiresAt, Ext, PartPlan, TransferId, TransferMode, TransferTarget } from "../../../../../_shared/components.js";
+
+
+/**
+ * Open an upload of one file's ciphertext into a data room, committing to its size and to the digest of every chunk before any byte moves, reserving room for it against every limit that applies, and saying how its bytes may move — straight to the room's storage, or through the host under a single-use upload key. The outer document members are owned by the framework — SPEC §6.3.
+ */
+export interface RoomsBlobsUploadBeginPayload {
+  /**
+   * The room the file is for. The host verifies the presentation against credentials this identifier issued, never against a member list of its own.
+   */
+  roomId: string;
+  /**
+   * Must confer the `write` action at this room's scope. Its leaf's subject must be the party the host authenticated for this request.
+   */
+  presentation: AuthorityPresentation;
+  /**
+   * A did:key the producer generated for this upload alone, for a proxied transfer: it signs the upload's chunk, commit and abort documents, and nothing else, and the host never records it as the owner or the uploader. Ed25519 (`z6Mk…`) MUST be accepted. A producer that omits it accepts only direct transfer.
+   */
+  uploadKey?: string;
+  /**
+   * The ciphertext manifest. Its digest is the BlobRef the blob will have once committed.
+   */
+  manifest: BlobManifest;
+  /**
+   * How the producer will cut the blob for direct transfer. Present means the producer accepts direct transfer; absent means it accepts only proxied.
+   */
+  directParts?: PartPlan;
+  ext?: Ext;
+}
+/**
+ * Success response to rooms/blobs/upload/begin. Type https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2#response.
+ */
+export interface RoomsBlobsUploadBeginResponsePayload {
+  uploadId: TransferId;
+  /**
+   * How this upload's bytes move: `direct` to the room's storage over `targets`, or `proxied` through the host as rooms/blobs/upload/chunk documents signed by `uploadKey`.
+   */
+  mode: TransferMode;
+  /**
+   * The indices the host does not yet hold, in ascending order: chunk indices in proxied mode, part indices in direct mode. Every index on a new upload; only what is left on a resumed one; none when `alreadyCommitted` is true. Empty means the upload can be committed.
+   *
+   * @maxItems 4096
+   */
+  missing: ChunkIndex[];
+  expiresAt: ExpiresAt;
+  /**
+   * Direct mode only: a PUT target for each of some or all of the `missing` parts. A host MAY issue targets for only some of them; the producer begins again, with the identical manifest and plan, for the rest and for any whose target lapsed. Absent in proxied mode.
+   *
+   * @maxItems 128
+   */
+  targets?: TransferTarget[];
+  /**
+   * True when the manifest's BlobRef is already committed in this room. `missing` is then empty, nothing was reserved, and commit returns the existing blob without charging it again. Absent or false on every other answer.
+   */
+  alreadyCommitted?: boolean;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AuthorityPresentation, BlobManifest, ChunkCount, ChunkIndex, ChunkManifest, ChunkSize, DigestMultibase, ExpectedSizeBytes, ExpiresAt, Ext, PartPlan, TransferId, TransferMode, TransferTarget };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsBlobsUploadBeginPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsBlobsUploadBeginResponsePayload;
+
+/**
+ * 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 const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2",
+  "title": "Rooms Blobs — Upload — Begin — payload",
+  "description": "Open an upload of one file's ciphertext into a data room, committing to its size and to the digest of every chunk before any byte moves, reserving room for it against every limit that applies, and saying how its bytes may move — straight to the room's storage, or through the host under a single-use upload key. The outer document members are owned by the framework — SPEC §6.3.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "roomId",
+    "presentation",
+    "manifest"
+  ],
+  "properties": {
+    "roomId": {
+      "type": "string",
+      "maxLength": 2048,
+      "description": "The room the file is for. The host verifies the presentation against credentials this identifier issued, never against a member list of its own."
+    },
+    "presentation": {
+      "$ref": "#/$defs/AuthorityPresentation",
+      "description": "Must confer the `write` action at this room's scope. Its leaf's subject must be the party the host authenticated for this request."
+    },
+    "uploadKey": {
+      "type": "string",
+      "pattern": "^did:key:z[1-9A-HJ-NP-Za-km-z]+$",
+      "maxLength": 256,
+      "description": "A did:key the producer generated for this upload alone, for a proxied transfer: it signs the upload's chunk, commit and abort documents, and nothing else, and the host never records it as the owner or the uploader. Ed25519 (`z6Mk…`) MUST be accepted. A producer that omits it accepts only direct transfer."
+    },
+    "manifest": {
+      "$ref": "#/$defs/BlobManifest",
+      "description": "The ciphertext manifest. Its digest is the BlobRef the blob will have once committed."
+    },
+    "directParts": {
+      "$ref": "#/$defs/PartPlan",
+      "description": "How the producer will cut the blob for direct transfer. Present means the producer accepts direct transfer; absent means it accepts only proxied."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Blobs — Upload — Begin — response payload",
+      "description": "Success response to rooms/blobs/upload/begin. Type https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2#response.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "uploadId",
+        "mode",
+        "missing",
+        "expiresAt"
+      ],
+      "properties": {
+        "uploadId": {
+          "$ref": "#/$defs/TransferId"
+        },
+        "mode": {
+          "$ref": "#/$defs/TransferMode",
+          "description": "How this upload's bytes move: `direct` to the room's storage over `targets`, or `proxied` through the host as rooms/blobs/upload/chunk documents signed by `uploadKey`."
+        },
+        "missing": {
+          "type": "array",
+          "maxItems": 4096,
+          "uniqueItems": true,
+          "items": {
+            "$ref": "#/$defs/ChunkIndex"
+          },
+          "description": "The indices the host does not yet hold, in ascending order: chunk indices in proxied mode, part indices in direct mode. Every index on a new upload; only what is left on a resumed one; none when `alreadyCommitted` is true. Empty means the upload can be committed."
+        },
+        "expiresAt": {
+          "$ref": "#/$defs/ExpiresAt"
+        },
+        "targets": {
+          "type": "array",
+          "maxItems": 128,
+          "items": {
+            "$ref": "#/$defs/TransferTarget"
+          },
+          "description": "Direct mode only: a PUT target for each of some or all of the `missing` parts. A host MAY issue targets for only some of them; the producer begins again, with the identical manifest and plan, for the rest and for any whose target lapsed. Absent in proxied mode."
+        },
+        "alreadyCommitted": {
+          "type": "boolean",
+          "description": "True when the manifest's BlobRef is already committed in this room. `missing` is then empty, nothing was reserved, and commit returns the existing blob without charging it again. Absent or false on every other answer."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "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.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "TransferTarget": {
+      "title": "TransferTarget",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "index",
+        "method",
+        "url",
+        "expiresAt"
+      ],
+      "description": "One time-limited URL at the room's storage, issued by the host for one object and one method. A bearer credential for its lifetime: whoever holds it may perform exactly that request. A host MUST bind it to one object, one method and — for a write — the part's exact length and checksum, so that storage itself refuses any other bytes, and MUST give it the shortest practical lifetime, never more than 5 minutes. No party logs it.",
+      "properties": {
+        "index": {
+          "type": "integer",
+          "minimum": 0,
+          "maximum": 1023,
+          "description": "The part this target writes, or 0 for a read of the whole object."
+        },
+        "method": {
+          "type": "string",
+          "enum": [
+            "PUT",
+            "GET"
+          ]
+        },
+        "url": {
+          "type": "string",
+          "format": "uri",
+          "pattern": "^https://",
+          "maxLength": 8192,
+          "description": "Where to send the request. HTTPS only."
+        },
+        "headers": {
+          "type": "object",
+          "maxProperties": 16,
+          "additionalProperties": {
+            "type": "string",
+            "maxLength": 1024
+          },
+          "propertyNames": {
+            "maxLength": 128
+          },
+          "description": "Headers the request MUST carry exactly as given — for a write, the part's length and checksum, which the URL's signature covers. A client adds nothing the storage would treat as signed."
+        },
+        "expiresAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "When the storage stops honouring the URL. A request begun after it is refused by the storage."
+        }
+      }
+    },
+    "ExpiresAt": {
+      "title": "ExpiresAt",
+      "description": "After which the bundle is collected: staged bytes discarded, tokens and chunk requests refused. Short by design. For a chunked transfer a recipient may move it later as chunks are exchanged, never past its own ceiling — each chunk response reports the current value.",
+      "type": "string",
+      "format": "date-time"
+    },
+    "ChunkIndex": {
+      "title": "ChunkIndex",
+      "description": "Zero-based position of a chunk within its bundle. Valid values are 0 to chunkCount − 1; an index outside that range is refused with chunkOutOfRange rather than validated here, because the bound depends on the bundle.",
+      "type": "integer",
+      "minimum": 0,
+      "maximum": 4095
+    },
+    "TransferMode": {
+      "title": "TransferMode",
+      "type": "string",
+      "enum": [
+        "direct",
+        "proxied"
+      ],
+      "description": "How a blob's bytes move. `proxied`: through the host, as chunk documents (rooms/blobs/upload/chunk, rooms/blobs/chunk). `direct`: straight between the member and the storage the room is assigned to, over time-limited URLs the host issues for one object and one method each; the host authorizes every object and verifies every upload, and never carries a byte. Which mode applies is the host's answer, from what the producer accepts, what the room's storage can do, and the room's tier."
+    },
+    "TransferId": {
+      "title": "TransferId",
+      "type": "string",
+      "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$",
+      "description": "Handle for one upload (begin → chunk → commit or abort) or one download (get → chunk). Host-generated and unguessable, which is what lets a reference to another party's transfer be answered as not-found without confirming that it exists. Bound at creation to the party that opened it: the subject the host authenticated for the opening request. Opaque: a producer quotes what it was given."
+    },
+    "PartPlan": {
+      "title": "PartPlan",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "partSize",
+        "partCount",
+        "partDigests"
+      ],
+      "description": "How the uploader will cut a blob for direct transfer, committed before any byte moves: one storage object, written in `partCount` parts of `partSize` bytes (the last may be shorter), each with its digest. Independent of the chunk manifest, because storage imposes part sizes a chunk document cannot carry; the chunk manifest still describes the blob and readers still check it.\n\nConsistency rules JSON Schema cannot state: `partCount` MUST equal ceil(size / partSize) for the manifest's `size`, and `partDigests` MUST have exactly `partCount` items. Every digest MUST be sha2-256, because it is what the storage itself checks the part against.",
+      "properties": {
+        "partSize": {
+          "type": "integer",
+          "minimum": 1,
+          "maximum": 1073741824,
+          "description": "Bytes per part. One part of the whole blob's size is a single-object write."
+        },
+        "partCount": {
+          "type": "integer",
+          "minimum": 1,
+          "maximum": 1024
+        },
+        "partDigests": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 1024,
+          "items": {
+            "$ref": "#/$defs/DigestMultibase"
+          },
+          "description": "The sha2-256 digest of each part's ciphertext, in order."
+        }
+      }
+    },
+    "DigestMultibase": {
+      "title": "DigestMultibase",
+      "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`.",
+      "type": "string",
+      "minLength": 16,
+      "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+      "examples": [
+        "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+      ]
+    },
+    "BlobManifest": {
+      "title": "BlobManifest",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "size",
+        "chunks",
+        "digest"
+      ],
+      "description": "The ciphertext manifest of one blob, committed by the uploader before any byte moves. Its digest is the BlobRef. Every chunk is checked against `chunks.chunkDigests` on arrival and the reassembled blob against `digest`, so a host can neither accept nor serve bytes the uploader did not commit to. The manifest also appears, by its BlobRef, inside the sealed FileManifest the author signs; a reader who opens the record therefore knows which ciphertext its author meant, and a host cannot substitute a different blob under the same record.\n\nConsistency rules JSON Schema cannot state: `chunks.chunkCount` MUST equal ceil(size / chunks.chunkSize), and `chunks.chunkDigests` MUST have exactly `chunkCount` items. A party receiving a manifest violating either MUST refuse it.\n\nEach transfer chunk is exactly one sealed STREAM segment (see FileManifest): every chunk but the last is `chunkSize` bytes, and `chunkSize` is the plaintext segment size plus the 16-byte AEAD tag. The 262144-byte ceiling of ChunkSize therefore puts the largest plaintext segment at 262128 bytes, and the 4096-chunk ceiling of ChunkCount puts the largest blob at 1 GiB of ciphertext.",
+      "properties": {
+        "size": {
+          "$ref": "#/$defs/ExpectedSizeBytes",
+          "description": "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in."
+        },
+        "chunks": {
+          "$ref": "#/$defs/ChunkManifest"
+        },
+        "digest": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest of the whole ciphertext, over its bytes. Checked after reassembly, so a correct set of chunks in the wrong order is still caught."
+        }
+      }
+    },
+    "ChunkManifest": {
+      "title": "ChunkManifest",
+      "description": "The terms of a `chunkedTrustTask` transfer, committed before any chunk moves. On export the recipient states them in the descriptor; on import the producer pre-commits them in the request and the recipient echoes them. Either way the manifest arrives in a document whose proof is REQUIRED, so the per-chunk digests are authenticated by the party that computed them and each chunk can be verified — and a single bad chunk re-fetched or refused — on arrival rather than only after reassembly.\n\nConsistency rules JSON Schema cannot state: `chunkCount` MUST equal ceil(expectedSizeBytes / chunkSize) for the bundle the manifest describes, and `chunkDigests` MUST have exactly `chunkCount` items. A party receiving a manifest violating either MUST refuse it.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "chunkSize",
+        "chunkCount",
+        "chunkDigests"
+      ],
+      "properties": {
+        "chunkSize": {
+          "$ref": "#/$defs/ChunkSize"
+        },
+        "chunkCount": {
+          "$ref": "#/$defs/ChunkCount"
+        },
+        "chunkDigests": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 4096,
+          "description": "Digest of each chunk's raw bytes (not of its base64url encoding), in index order. Compared as decoded multihash bytes, never as encoded strings. sha2-256 is RECOMMENDED and MUST be implemented by every party; a party that does not implement the hash a digest names MUST treat the manifest as unverifiable rather than skip the check.",
+          "items": {
+            "$ref": "#/$defs/DigestMultibase"
+          }
+        }
+      }
+    },
+    "ChunkCount": {
+      "title": "ChunkCount",
+      "description": "Number of chunks in the bundle, equal to ceil(expectedSizeBytes / chunkSize). Bounded at 4096 so that the manifest itself — one digest per chunk — fits in the single document that carries it under the same message-size reasoning as a chunk.",
+      "type": "integer",
+      "minimum": 1,
+      "maximum": 4096
+    },
+    "ChunkSize": {
+      "title": "ChunkSize",
+      "description": "Size in bytes of every chunk except the last, which carries the remainder and is between 1 and this value inclusive. The ceiling of 262144 (256 KiB) is normative and is derived in `vta/backup/initiate-export/1.1` under Chunked transfer: it is the largest power of two whose `get-chunk` or `put-chunk` document still fits a 1 MiB mediator message after base64url encoding of `data`, DIDComm authcrypt encoding, and two nested forward wrappers. The floor of 16384 keeps a 1 GiB bundle within `ChunkCount`'s ceiling at sizes a constrained transport can still choose.",
+      "type": "integer",
+      "minimum": 16384,
+      "maximum": 262144
+    },
+    "ExpectedSizeBytes": {
+      "title": "ExpectedSizeBytes",
+      "description": "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.",
+      "type": "integer",
+      "minimum": 1
+    },
+    "AuthorityPresentation": {
+      "title": "AuthorityPresentation",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "membership",
+        "authority"
+      ],
+      "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.",
+      "properties": {
+        "membership": {
+          "type": "string",
+          "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."
+        },
+        "authority": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 8,
+          "items": {
+            "type": "string"
+          },
+          "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."
+        },
+        "subjectBinding": {
+          "type": "string",
+          "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 const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Blobs — Upload — Begin — response payload",
+      "description": "Success response to rooms/blobs/upload/begin. Type https://trusttasks.org/spec/rooms/blobs/upload/begin/0.2#response.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "uploadId",
+        "mode",
+        "missing",
+        "expiresAt"
+      ],
+      "properties": {
+        "uploadId": {
+          "$ref": "#/$defs/TransferId"
+        },
+        "mode": {
+          "$ref": "#/$defs/TransferMode",
+          "description": "How this upload's bytes move: `direct` to the room's storage over `targets`, or `proxied` through the host as rooms/blobs/upload/chunk documents signed by `uploadKey`."
+        },
+        "missing": {
+          "type": "array",
+          "maxItems": 4096,
+          "uniqueItems": true,
+          "items": {
+            "$ref": "#/$defs/ChunkIndex"
+          },
+          "description": "The indices the host does not yet hold, in ascending order: chunk indices in proxied mode, part indices in direct mode. Every index on a new upload; only what is left on a resumed one; none when `alreadyCommitted` is true. Empty means the upload can be committed."
+        },
+        "expiresAt": {
+          "$ref": "#/$defs/ExpiresAt"
+        },
+        "targets": {
+          "type": "array",
+          "maxItems": 128,
+          "items": {
+            "$ref": "#/$defs/TransferTarget"
+          },
+          "description": "Direct mode only: a PUT target for each of some or all of the `missing` parts. A host MAY issue targets for only some of them; the producer begins again, with the identical manifest and plan, for the rest and for any whose target lapsed. Absent in proxied mode."
+        },
+        "alreadyCommitted": {
+          "type": "boolean",
+          "description": "True when the manifest's BlobRef is already committed in this room. `missing` is then empty, nothing was reserved, and commit returns the existing blob without charging it again. Absent or false on every other answer."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "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.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "TransferTarget": {
+      "title": "TransferTarget",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "index",
+        "method",
+        "url",
+        "expiresAt"
+      ],
+      "description": "One time-limited URL at the room's storage, issued by the host for one object and one method. A bearer credential for its lifetime: whoever holds it may perform exactly that request. A host MUST bind it to one object, one method and — for a write — the part's exact length and checksum, so that storage itself refuses any other bytes, and MUST give it the shortest practical lifetime, never more than 5 minutes. No party logs it.",
+      "properties": {
+        "index": {
+          "type": "integer",
+          "minimum": 0,
+          "maximum": 1023,
+          "description": "The part this target writes, or 0 for a read of the whole object."
+        },
+        "method": {
+          "type": "string",
+          "enum": [
+            "PUT",
+            "GET"
+          ]
+        },
+        "url": {
+          "type": "string",
+          "format": "uri",
+          "pattern": "^https://",
+          "maxLength": 8192,
+          "description": "Where to send the request. HTTPS only."
+        },
+        "headers": {
+          "type": "object",
+          "maxProperties": 16,
+          "additionalProperties": {
+            "type": "string",
+            "maxLength": 1024
+          },
+          "propertyNames": {
+            "maxLength": 128
+          },
+          "description": "Headers the request MUST carry exactly as given — for a write, the part's length and checksum, which the URL's signature covers. A client adds nothing the storage would treat as signed."
+        },
+        "expiresAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "When the storage stops honouring the URL. A request begun after it is refused by the storage."
+        }
+      }
+    },
+    "ExpiresAt": {
+      "title": "ExpiresAt",
+      "description": "After which the bundle is collected: staged bytes discarded, tokens and chunk requests refused. Short by design. For a chunked transfer a recipient may move it later as chunks are exchanged, never past its own ceiling — each chunk response reports the current value.",
+      "type": "string",
+      "format": "date-time"
+    },
+    "ChunkIndex": {
+      "title": "ChunkIndex",
+      "description": "Zero-based position of a chunk within its bundle. Valid values are 0 to chunkCount − 1; an index outside that range is refused with chunkOutOfRange rather than validated here, because the bound depends on the bundle.",
+      "type": "integer",
+      "minimum": 0,
+      "maximum": 4095
+    },
+    "TransferMode": {
+      "title": "TransferMode",
+      "type": "string",
+      "enum": [
+        "direct",
+        "proxied"
+      ],
+      "description": "How a blob's bytes move. `proxied`: through the host, as chunk documents (rooms/blobs/upload/chunk, rooms/blobs/chunk). `direct`: straight between the member and the storage the room is assigned to, over time-limited URLs the host issues for one object and one method each; the host authorizes every object and verifies every upload, and never carries a byte. Which mode applies is the host's answer, from what the producer accepts, what the room's storage can do, and the room's tier."
+    },
+    "TransferId": {
+      "title": "TransferId",
+      "type": "string",
+      "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$",
+      "description": "Handle for one upload (begin → chunk → commit or abort) or one download (get → chunk). Host-generated and unguessable, which is what lets a reference to another party's transfer be answered as not-found without confirming that it exists. Bound at creation to the party that opened it: the subject the host authenticated for the opening request. Opaque: a producer quotes what it was given."
+    },
+    "PartPlan": {
+      "title": "PartPlan",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "partSize",
+        "partCount",
+        "partDigests"
+      ],
+      "description": "How the uploader will cut a blob for direct transfer, committed before any byte moves: one storage object, written in `partCount` parts of `partSize` bytes (the last may be shorter), each with its digest. Independent of the chunk manifest, because storage imposes part sizes a chunk document cannot carry; the chunk manifest still describes the blob and readers still check it.\n\nConsistency rules JSON Schema cannot state: `partCount` MUST equal ceil(size / partSize) for the manifest's `size`, and `partDigests` MUST have exactly `partCount` items. Every digest MUST be sha2-256, because it is what the storage itself checks the part against.",
+      "properties": {
+        "partSize": {
+          "type": "integer",
+          "minimum": 1,
+          "maximum": 1073741824,
+          "description": "Bytes per part. One part of the whole blob's size is a single-object write."
+        },
+        "partCount": {
+          "type": "integer",
+          "minimum": 1,
+          "maximum": 1024
+        },
+        "partDigests": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 1024,
+          "items": {
+            "$ref": "#/$defs/DigestMultibase"
+          },
+          "description": "The sha2-256 digest of each part's ciphertext, in order."
+        }
+      }
+    },
+    "DigestMultibase": {
+      "title": "DigestMultibase",
+      "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`.",
+      "type": "string",
+      "minLength": 16,
+      "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+      "examples": [
+        "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+      ]
+    },
+    "BlobManifest": {
+      "title": "BlobManifest",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "size",
+        "chunks",
+        "digest"
+      ],
+      "description": "The ciphertext manifest of one blob, committed by the uploader before any byte moves. Its digest is the BlobRef. Every chunk is checked against `chunks.chunkDigests` on arrival and the reassembled blob against `digest`, so a host can neither accept nor serve bytes the uploader did not commit to. The manifest also appears, by its BlobRef, inside the sealed FileManifest the author signs; a reader who opens the record therefore knows which ciphertext its author meant, and a host cannot substitute a different blob under the same record.\n\nConsistency rules JSON Schema cannot state: `chunks.chunkCount` MUST equal ceil(size / chunks.chunkSize), and `chunks.chunkDigests` MUST have exactly `chunkCount` items. A party receiving a manifest violating either MUST refuse it.\n\nEach transfer chunk is exactly one sealed STREAM segment (see FileManifest): every chunk but the last is `chunkSize` bytes, and `chunkSize` is the plaintext segment size plus the 16-byte AEAD tag. The 262144-byte ceiling of ChunkSize therefore puts the largest plaintext segment at 262128 bytes, and the 4096-chunk ceiling of ChunkCount puts the largest blob at 1 GiB of ciphertext.",
+      "properties": {
+        "size": {
+          "$ref": "#/$defs/ExpectedSizeBytes",
+          "description": "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in."
+        },
+        "chunks": {
+          "$ref": "#/$defs/ChunkManifest"
+        },
+        "digest": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest of the whole ciphertext, over its bytes. Checked after reassembly, so a correct set of chunks in the wrong order is still caught."
+        }
+      }
+    },
+    "ChunkManifest": {
+      "title": "ChunkManifest",
+      "description": "The terms of a `chunkedTrustTask` transfer, committed before any chunk moves. On export the recipient states them in the descriptor; on import the producer pre-commits them in the request and the recipient echoes them. Either way the manifest arrives in a document whose proof is REQUIRED, so the per-chunk digests are authenticated by the party that computed them and each chunk can be verified — and a single bad chunk re-fetched or refused — on arrival rather than only after reassembly.\n\nConsistency rules JSON Schema cannot state: `chunkCount` MUST equal ceil(expectedSizeBytes / chunkSize) for the bundle the manifest describes, and `chunkDigests` MUST have exactly `chunkCount` items. A party receiving a manifest violating either MUST refuse it.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "chunkSize",
+        "chunkCount",
+        "chunkDigests"
+      ],
+      "properties": {
+        "chunkSize": {
+          "$ref": "#/$defs/ChunkSize"
+        },
+        "chunkCount": {
+          "$ref": "#/$defs/ChunkCount"
+        },
+        "chunkDigests": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 4096,
+          "description": "Digest of each chunk's raw bytes (not of its base64url encoding), in index order. Compared as decoded multihash bytes, never as encoded strings. sha2-256 is RECOMMENDED and MUST be implemented by every party; a party that does not implement the hash a digest names MUST treat the manifest as unverifiable rather than skip the check.",
+          "items": {
+            "$ref": "#/$defs/DigestMultibase"
+          }
+        }
+      }
+    },
+    "ChunkCount": {
+      "title": "ChunkCount",
+      "description": "Number of chunks in the bundle, equal to ceil(expectedSizeBytes / chunkSize). Bounded at 4096 so that the manifest itself — one digest per chunk — fits in the single document that carries it under the same message-size reasoning as a chunk.",
+      "type": "integer",
+      "minimum": 1,
+      "maximum": 4096
+    },
+    "ChunkSize": {
+      "title": "ChunkSize",
+      "description": "Size in bytes of every chunk except the last, which carries the remainder and is between 1 and this value inclusive. The ceiling of 262144 (256 KiB) is normative and is derived in `vta/backup/initiate-export/1.1` under Chunked transfer: it is the largest power of two whose `get-chunk` or `put-chunk` document still fits a 1 MiB mediator message after base64url encoding of `data`, DIDComm authcrypt encoding, and two nested forward wrappers. The floor of 16384 keeps a 1 GiB bundle within `ChunkCount`'s ceiling at sizes a constrained transport can still choose.",
+      "type": "integer",
+      "minimum": 16384,
+      "maximum": 262144
+    },
+    "ExpectedSizeBytes": {
+      "title": "ExpectedSizeBytes",
+      "description": "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.",
+      "type": "integer",
+      "minimum": 1
+    },
+    "AuthorityPresentation": {
+      "title": "AuthorityPresentation",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "membership",
+        "authority"
+      ],
+      "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.",
+      "properties": {
+        "membership": {
+          "type": "string",
+          "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."
+        },
+        "authority": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 8,
+          "items": {
+            "type": "string"
+          },
+          "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."
+        },
+        "subjectBinding": {
+          "type": "string",
+          "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 const;
+
+/**
+ * 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 const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * 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 const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;