@openvtc/trust-tasks 0.26.3 → 0.26.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (48) hide show
  1. package/CHANGELOG.md +38 -0
  2. package/dist/_shared/components.d.ts +47 -0
  3. package/dist/_shared/components.d.ts.map +1 -1
  4. package/dist/index.d.ts +7 -0
  5. package/dist/index.d.ts.map +1 -1
  6. package/dist/index.js +7 -0
  7. package/dist/index.js.map +1 -1
  8. package/dist/rooms/_shared/0.1/blobs.d.ts +1 -1
  9. package/dist/rooms/_shared/0.1/blobs.d.ts.map +1 -1
  10. package/dist/rooms/blobs/get/0.2/payload.d.ts +1005 -0
  11. package/dist/rooms/blobs/get/0.2/payload.d.ts.map +1 -0
  12. package/dist/rooms/blobs/get/0.2/payload.js +559 -0
  13. package/dist/rooms/blobs/get/0.2/payload.js.map +1 -0
  14. package/dist/rooms/blobs/upload/abort/0.2/payload.d.ts +263 -0
  15. package/dist/rooms/blobs/upload/abort/0.2/payload.d.ts.map +1 -0
  16. package/dist/rooms/blobs/upload/abort/0.2/payload.js +151 -0
  17. package/dist/rooms/blobs/upload/abort/0.2/payload.js.map +1 -0
  18. package/dist/rooms/blobs/upload/begin/0.2/payload.d.ts +1191 -0
  19. package/dist/rooms/blobs/upload/begin/0.2/payload.d.ts.map +1 -0
  20. package/dist/rooms/blobs/upload/begin/0.2/payload.js +659 -0
  21. package/dist/rooms/blobs/upload/begin/0.2/payload.js.map +1 -0
  22. package/dist/rooms/blobs/upload/chunk/0.2/payload.d.ts +459 -0
  23. package/dist/rooms/blobs/upload/chunk/0.2/payload.d.ts.map +1 -0
  24. package/dist/rooms/blobs/upload/chunk/0.2/payload.js +256 -0
  25. package/dist/rooms/blobs/upload/chunk/0.2/payload.js.map +1 -0
  26. package/dist/rooms/blobs/upload/commit/0.2/payload.d.ts +326 -0
  27. package/dist/rooms/blobs/upload/commit/0.2/payload.d.ts.map +1 -0
  28. package/dist/rooms/blobs/upload/commit/0.2/payload.js +185 -0
  29. package/dist/rooms/blobs/upload/commit/0.2/payload.js.map +1 -0
  30. package/dist/rooms/keys/act/0.1/payload.d.ts +546 -0
  31. package/dist/rooms/keys/act/0.1/payload.d.ts.map +1 -0
  32. package/dist/rooms/keys/act/0.1/payload.js +305 -0
  33. package/dist/rooms/keys/act/0.1/payload.js.map +1 -0
  34. package/dist/rooms/keys/seal/0.2/payload.d.ts +368 -0
  35. package/dist/rooms/keys/seal/0.2/payload.d.ts.map +1 -0
  36. package/dist/rooms/keys/seal/0.2/payload.js +205 -0
  37. package/dist/rooms/keys/seal/0.2/payload.js.map +1 -0
  38. package/package.json +1 -1
  39. package/src/_shared/components.ts +47 -0
  40. package/src/index.ts +7 -0
  41. package/src/rooms/_shared/0.1/blobs.ts +1 -1
  42. package/src/rooms/blobs/get/0.2/payload.ts +625 -0
  43. package/src/rooms/blobs/upload/abort/0.2/payload.ts +187 -0
  44. package/src/rooms/blobs/upload/begin/0.2/payload.ts +731 -0
  45. package/src/rooms/blobs/upload/chunk/0.2/payload.ts +304 -0
  46. package/src/rooms/blobs/upload/commit/0.2/payload.ts +224 -0
  47. package/src/rooms/keys/act/0.1/payload.ts +380 -0
  48. package/src/rooms/keys/seal/0.2/payload.ts +256 -0
@@ -0,0 +1,1005 @@
1
+ /**
2
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
3
+ * Source: specs/rooms/blobs/get/0.2/payload.schema.json
4
+ */
5
+ import type { AuthorityPresentation, BlobManifest, BlobRef, ChunkCount, ChunkManifest, ChunkSize, DigestMultibase, ExpectedSizeBytes, ExpiresAt, Ext, TransferId, TransferMode, TransferTarget } from "../../../../_shared/components.js";
6
+ /**
7
+ * Open a download of one blob committed in a data room: the host returns its ciphertext manifest and either a time-limited storage URL for the object (direct) or a handle for fetching its chunks through the host (proxied). The outer document members are owned by the framework — SPEC §6.3.
8
+ */
9
+ export interface RoomsBlobsGetPayload {
10
+ /**
11
+ * The room the blob belongs to. The host verifies the presentation against credentials this identifier issued.
12
+ */
13
+ roomId: string;
14
+ /**
15
+ * Must confer the `read` action at this room's scope. Its leaf's subject must be the party the host authenticated for this request.
16
+ */
17
+ presentation: AuthorityPresentation;
18
+ /**
19
+ * The blob to fetch, as the record's `blobs` member names it.
20
+ */
21
+ blobRef: BlobRef;
22
+ /**
23
+ * True when the producer accepts a storage URL for the object. Absent or false: the host answers in proxied mode.
24
+ */
25
+ direct?: boolean;
26
+ ext?: Ext;
27
+ }
28
+ /**
29
+ * Success response to rooms/blobs/get. Type https://trusttasks.org/spec/rooms/blobs/get/0.2#response.
30
+ */
31
+ export interface RoomsBlobsGetResponsePayload {
32
+ /**
33
+ * `direct`: fetch the object over `target`. `proxied`: fetch its chunks with rooms/blobs/chunk under `downloadId`.
34
+ */
35
+ mode: TransferMode;
36
+ /**
37
+ * The ciphertext manifest committed at upload. A reader MUST check that its digest equals the requested BlobRef before relying on it, and every chunk against it on arrival.
38
+ */
39
+ manifest: BlobManifest;
40
+ /**
41
+ * Proxied mode only: the download handle for rooms/blobs/chunk. Absent in direct mode.
42
+ */
43
+ downloadId?: TransferId;
44
+ /**
45
+ * Direct mode only: a GET for the one object holding this blob, expiring within minutes. Ranged requests MAY be permitted. Absent in proxied mode.
46
+ */
47
+ target?: TransferTarget;
48
+ /**
49
+ * When the handle (proxied) or the target (direct) stops being honoured.
50
+ */
51
+ expiresAt: ExpiresAt;
52
+ ext?: Ext;
53
+ }
54
+ /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
55
+ export type { AuthorityPresentation, BlobManifest, BlobRef, ChunkCount, ChunkManifest, ChunkSize, DigestMultibase, ExpectedSizeBytes, ExpiresAt, Ext, TransferId, TransferMode, TransferTarget };
56
+ /** Trust Task type URI. */
57
+ export declare const TYPE_URI: "https://trusttasks.org/spec/rooms/blobs/get/0.2";
58
+ /** Stable alias for this specification's request payload shape. */
59
+ export type Payload = RoomsBlobsGetPayload;
60
+ /** Trust Task response type URI (request type URI + "#response"). */
61
+ export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/rooms/blobs/get/0.2#response";
62
+ /** Stable alias for this specification's success-response payload shape. */
63
+ export type Response = RoomsBlobsGetResponsePayload;
64
+ /**
65
+ * This specification's payload schema, as a value.
66
+ *
67
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
68
+ * rather than only as a `.json` file because TypeScript types are erased
69
+ * at runtime: without a schema a consumer has nothing to validate, and
70
+ * every REQUIRED payload member is optional in practice. Cross-file
71
+ * `$ref`s are already inlined, so it needs no resolver.
72
+ */
73
+ export declare const PAYLOAD_SCHEMA: {
74
+ readonly $schema: "https://json-schema.org/draft/2020-12/schema";
75
+ readonly $id: "https://trusttasks.org/spec/rooms/blobs/get/0.2";
76
+ readonly title: "Rooms Blobs — Get — payload";
77
+ readonly description: "Open a download of one blob committed in a data room: the host returns its ciphertext manifest and either a time-limited storage URL for the object (direct) or a handle for fetching its chunks through the host (proxied). The outer document members are owned by the framework — SPEC §6.3.";
78
+ readonly type: "object";
79
+ readonly additionalProperties: false;
80
+ readonly required: readonly ["roomId", "presentation", "blobRef"];
81
+ readonly properties: {
82
+ readonly roomId: {
83
+ readonly type: "string";
84
+ readonly maxLength: 2048;
85
+ readonly description: "The room the blob belongs to. The host verifies the presentation against credentials this identifier issued.";
86
+ };
87
+ readonly presentation: {
88
+ readonly $ref: "#/$defs/AuthorityPresentation";
89
+ readonly description: "Must confer the `read` action at this room's scope. Its leaf's subject must be the party the host authenticated for this request.";
90
+ };
91
+ readonly blobRef: {
92
+ readonly $ref: "#/$defs/BlobRef";
93
+ readonly description: "The blob to fetch, as the record's `blobs` member names it.";
94
+ };
95
+ readonly direct: {
96
+ readonly type: "boolean";
97
+ readonly description: "True when the producer accepts a storage URL for the object. Absent or false: the host answers in proxied mode.";
98
+ };
99
+ readonly ext: {
100
+ readonly $ref: "#/$defs/Ext";
101
+ };
102
+ };
103
+ readonly $defs: {
104
+ readonly Response: {
105
+ readonly $anchor: "response";
106
+ readonly title: "Rooms Blobs — Get — response payload";
107
+ readonly description: "Success response to rooms/blobs/get. Type https://trusttasks.org/spec/rooms/blobs/get/0.2#response.";
108
+ readonly type: "object";
109
+ readonly additionalProperties: false;
110
+ readonly required: readonly ["mode", "manifest", "expiresAt"];
111
+ readonly properties: {
112
+ readonly mode: {
113
+ readonly $ref: "#/$defs/TransferMode";
114
+ readonly description: "`direct`: fetch the object over `target`. `proxied`: fetch its chunks with rooms/blobs/chunk under `downloadId`.";
115
+ };
116
+ readonly manifest: {
117
+ readonly $ref: "#/$defs/BlobManifest";
118
+ readonly description: "The ciphertext manifest committed at upload. A reader MUST check that its digest equals the requested BlobRef before relying on it, and every chunk against it on arrival.";
119
+ };
120
+ readonly downloadId: {
121
+ readonly $ref: "#/$defs/TransferId";
122
+ readonly description: "Proxied mode only: the download handle for rooms/blobs/chunk. Absent in direct mode.";
123
+ };
124
+ readonly target: {
125
+ readonly $ref: "#/$defs/TransferTarget";
126
+ readonly description: "Direct mode only: a GET for the one object holding this blob, expiring within minutes. Ranged requests MAY be permitted. Absent in proxied mode.";
127
+ };
128
+ readonly expiresAt: {
129
+ readonly $ref: "#/$defs/ExpiresAt";
130
+ readonly description: "When the handle (proxied) or the target (direct) stops being honoured.";
131
+ };
132
+ readonly ext: {
133
+ readonly $ref: "#/$defs/Ext";
134
+ };
135
+ };
136
+ };
137
+ readonly Ext: {
138
+ readonly title: "Ext";
139
+ 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.";
140
+ readonly type: "object";
141
+ readonly minProperties: 1;
142
+ readonly additionalProperties: true;
143
+ readonly propertyNames: {
144
+ readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
145
+ };
146
+ };
147
+ readonly ExpiresAt: {
148
+ readonly title: "ExpiresAt";
149
+ readonly 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.";
150
+ readonly type: "string";
151
+ readonly format: "date-time";
152
+ };
153
+ readonly TransferTarget: {
154
+ readonly title: "TransferTarget";
155
+ readonly type: "object";
156
+ readonly additionalProperties: false;
157
+ readonly required: readonly ["index", "method", "url", "expiresAt"];
158
+ readonly 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.";
159
+ readonly properties: {
160
+ readonly index: {
161
+ readonly type: "integer";
162
+ readonly minimum: 0;
163
+ readonly maximum: 1023;
164
+ readonly description: "The part this target writes, or 0 for a read of the whole object.";
165
+ };
166
+ readonly method: {
167
+ readonly type: "string";
168
+ readonly enum: readonly ["PUT", "GET"];
169
+ };
170
+ readonly url: {
171
+ readonly type: "string";
172
+ readonly format: "uri";
173
+ readonly pattern: "^https://";
174
+ readonly maxLength: 8192;
175
+ readonly description: "Where to send the request. HTTPS only.";
176
+ };
177
+ readonly headers: {
178
+ readonly type: "object";
179
+ readonly maxProperties: 16;
180
+ readonly additionalProperties: {
181
+ readonly type: "string";
182
+ readonly maxLength: 1024;
183
+ };
184
+ readonly propertyNames: {
185
+ readonly maxLength: 128;
186
+ };
187
+ readonly 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.";
188
+ };
189
+ readonly expiresAt: {
190
+ readonly type: "string";
191
+ readonly format: "date-time";
192
+ readonly description: "When the storage stops honouring the URL. A request begun after it is refused by the storage.";
193
+ };
194
+ };
195
+ };
196
+ readonly TransferId: {
197
+ readonly title: "TransferId";
198
+ readonly type: "string";
199
+ readonly 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}$";
200
+ readonly 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.";
201
+ };
202
+ readonly BlobManifest: {
203
+ readonly title: "BlobManifest";
204
+ readonly type: "object";
205
+ readonly additionalProperties: false;
206
+ readonly required: readonly ["size", "chunks", "digest"];
207
+ readonly 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.";
208
+ readonly properties: {
209
+ readonly size: {
210
+ readonly $ref: "#/$defs/ExpectedSizeBytes";
211
+ readonly description: "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in.";
212
+ };
213
+ readonly chunks: {
214
+ readonly $ref: "#/$defs/ChunkManifest";
215
+ };
216
+ readonly digest: {
217
+ readonly $ref: "#/$defs/DigestMultibase";
218
+ readonly 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.";
219
+ };
220
+ };
221
+ };
222
+ readonly DigestMultibase: {
223
+ readonly title: "DigestMultibase";
224
+ 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`.";
225
+ readonly type: "string";
226
+ readonly minLength: 16;
227
+ readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
228
+ readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
229
+ };
230
+ readonly ChunkManifest: {
231
+ readonly title: "ChunkManifest";
232
+ readonly 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.";
233
+ readonly type: "object";
234
+ readonly additionalProperties: false;
235
+ readonly required: readonly ["chunkSize", "chunkCount", "chunkDigests"];
236
+ readonly properties: {
237
+ readonly chunkSize: {
238
+ readonly $ref: "#/$defs/ChunkSize";
239
+ };
240
+ readonly chunkCount: {
241
+ readonly $ref: "#/$defs/ChunkCount";
242
+ };
243
+ readonly chunkDigests: {
244
+ readonly type: "array";
245
+ readonly minItems: 1;
246
+ readonly maxItems: 4096;
247
+ readonly 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.";
248
+ readonly items: {
249
+ readonly $ref: "#/$defs/DigestMultibase";
250
+ };
251
+ };
252
+ };
253
+ };
254
+ readonly ChunkCount: {
255
+ readonly title: "ChunkCount";
256
+ readonly 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.";
257
+ readonly type: "integer";
258
+ readonly minimum: 1;
259
+ readonly maximum: 4096;
260
+ };
261
+ readonly ChunkSize: {
262
+ readonly title: "ChunkSize";
263
+ readonly 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.";
264
+ readonly type: "integer";
265
+ readonly minimum: 16384;
266
+ readonly maximum: 262144;
267
+ };
268
+ readonly ExpectedSizeBytes: {
269
+ readonly title: "ExpectedSizeBytes";
270
+ readonly description: "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.";
271
+ readonly type: "integer";
272
+ readonly minimum: 1;
273
+ };
274
+ readonly TransferMode: {
275
+ readonly title: "TransferMode";
276
+ readonly type: "string";
277
+ readonly enum: readonly ["direct", "proxied"];
278
+ readonly 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.";
279
+ };
280
+ readonly BlobRef: {
281
+ readonly title: "BlobRef";
282
+ 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.";
283
+ readonly $ref: "#/$defs/DigestMultibase";
284
+ };
285
+ readonly AuthorityPresentation: {
286
+ readonly title: "AuthorityPresentation";
287
+ readonly type: "object";
288
+ readonly additionalProperties: false;
289
+ readonly required: readonly ["membership", "authority"];
290
+ 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.";
291
+ readonly properties: {
292
+ readonly membership: {
293
+ readonly type: "string";
294
+ 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.";
295
+ };
296
+ readonly authority: {
297
+ readonly type: "array";
298
+ readonly minItems: 1;
299
+ readonly maxItems: 8;
300
+ readonly items: {
301
+ readonly type: "string";
302
+ };
303
+ 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.";
304
+ };
305
+ readonly subjectBinding: {
306
+ readonly type: "string";
307
+ 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.";
308
+ };
309
+ };
310
+ };
311
+ };
312
+ };
313
+ /** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
314
+ export declare const RESPONSE_PAYLOAD_SCHEMA: {
315
+ readonly $schema: "https://json-schema.org/draft/2020-12/schema";
316
+ readonly $ref: "#/$defs/Response";
317
+ readonly $defs: {
318
+ readonly Response: {
319
+ readonly $anchor: "response";
320
+ readonly title: "Rooms Blobs — Get — response payload";
321
+ readonly description: "Success response to rooms/blobs/get. Type https://trusttasks.org/spec/rooms/blobs/get/0.2#response.";
322
+ readonly type: "object";
323
+ readonly additionalProperties: false;
324
+ readonly required: readonly ["mode", "manifest", "expiresAt"];
325
+ readonly properties: {
326
+ readonly mode: {
327
+ readonly $ref: "#/$defs/TransferMode";
328
+ readonly description: "`direct`: fetch the object over `target`. `proxied`: fetch its chunks with rooms/blobs/chunk under `downloadId`.";
329
+ };
330
+ readonly manifest: {
331
+ readonly $ref: "#/$defs/BlobManifest";
332
+ readonly description: "The ciphertext manifest committed at upload. A reader MUST check that its digest equals the requested BlobRef before relying on it, and every chunk against it on arrival.";
333
+ };
334
+ readonly downloadId: {
335
+ readonly $ref: "#/$defs/TransferId";
336
+ readonly description: "Proxied mode only: the download handle for rooms/blobs/chunk. Absent in direct mode.";
337
+ };
338
+ readonly target: {
339
+ readonly $ref: "#/$defs/TransferTarget";
340
+ readonly description: "Direct mode only: a GET for the one object holding this blob, expiring within minutes. Ranged requests MAY be permitted. Absent in proxied mode.";
341
+ };
342
+ readonly expiresAt: {
343
+ readonly $ref: "#/$defs/ExpiresAt";
344
+ readonly description: "When the handle (proxied) or the target (direct) stops being honoured.";
345
+ };
346
+ readonly ext: {
347
+ readonly $ref: "#/$defs/Ext";
348
+ };
349
+ };
350
+ };
351
+ readonly Ext: {
352
+ readonly title: "Ext";
353
+ 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.";
354
+ readonly type: "object";
355
+ readonly minProperties: 1;
356
+ readonly additionalProperties: true;
357
+ readonly propertyNames: {
358
+ readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
359
+ };
360
+ };
361
+ readonly ExpiresAt: {
362
+ readonly title: "ExpiresAt";
363
+ readonly 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.";
364
+ readonly type: "string";
365
+ readonly format: "date-time";
366
+ };
367
+ readonly TransferTarget: {
368
+ readonly title: "TransferTarget";
369
+ readonly type: "object";
370
+ readonly additionalProperties: false;
371
+ readonly required: readonly ["index", "method", "url", "expiresAt"];
372
+ readonly 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.";
373
+ readonly properties: {
374
+ readonly index: {
375
+ readonly type: "integer";
376
+ readonly minimum: 0;
377
+ readonly maximum: 1023;
378
+ readonly description: "The part this target writes, or 0 for a read of the whole object.";
379
+ };
380
+ readonly method: {
381
+ readonly type: "string";
382
+ readonly enum: readonly ["PUT", "GET"];
383
+ };
384
+ readonly url: {
385
+ readonly type: "string";
386
+ readonly format: "uri";
387
+ readonly pattern: "^https://";
388
+ readonly maxLength: 8192;
389
+ readonly description: "Where to send the request. HTTPS only.";
390
+ };
391
+ readonly headers: {
392
+ readonly type: "object";
393
+ readonly maxProperties: 16;
394
+ readonly additionalProperties: {
395
+ readonly type: "string";
396
+ readonly maxLength: 1024;
397
+ };
398
+ readonly propertyNames: {
399
+ readonly maxLength: 128;
400
+ };
401
+ readonly 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.";
402
+ };
403
+ readonly expiresAt: {
404
+ readonly type: "string";
405
+ readonly format: "date-time";
406
+ readonly description: "When the storage stops honouring the URL. A request begun after it is refused by the storage.";
407
+ };
408
+ };
409
+ };
410
+ readonly TransferId: {
411
+ readonly title: "TransferId";
412
+ readonly type: "string";
413
+ readonly 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}$";
414
+ readonly 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.";
415
+ };
416
+ readonly BlobManifest: {
417
+ readonly title: "BlobManifest";
418
+ readonly type: "object";
419
+ readonly additionalProperties: false;
420
+ readonly required: readonly ["size", "chunks", "digest"];
421
+ readonly 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.";
422
+ readonly properties: {
423
+ readonly size: {
424
+ readonly $ref: "#/$defs/ExpectedSizeBytes";
425
+ readonly description: "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in.";
426
+ };
427
+ readonly chunks: {
428
+ readonly $ref: "#/$defs/ChunkManifest";
429
+ };
430
+ readonly digest: {
431
+ readonly $ref: "#/$defs/DigestMultibase";
432
+ readonly 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.";
433
+ };
434
+ };
435
+ };
436
+ readonly DigestMultibase: {
437
+ readonly title: "DigestMultibase";
438
+ 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`.";
439
+ readonly type: "string";
440
+ readonly minLength: 16;
441
+ readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
442
+ readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
443
+ };
444
+ readonly ChunkManifest: {
445
+ readonly title: "ChunkManifest";
446
+ readonly 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.";
447
+ readonly type: "object";
448
+ readonly additionalProperties: false;
449
+ readonly required: readonly ["chunkSize", "chunkCount", "chunkDigests"];
450
+ readonly properties: {
451
+ readonly chunkSize: {
452
+ readonly $ref: "#/$defs/ChunkSize";
453
+ };
454
+ readonly chunkCount: {
455
+ readonly $ref: "#/$defs/ChunkCount";
456
+ };
457
+ readonly chunkDigests: {
458
+ readonly type: "array";
459
+ readonly minItems: 1;
460
+ readonly maxItems: 4096;
461
+ readonly 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.";
462
+ readonly items: {
463
+ readonly $ref: "#/$defs/DigestMultibase";
464
+ };
465
+ };
466
+ };
467
+ };
468
+ readonly ChunkCount: {
469
+ readonly title: "ChunkCount";
470
+ readonly 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.";
471
+ readonly type: "integer";
472
+ readonly minimum: 1;
473
+ readonly maximum: 4096;
474
+ };
475
+ readonly ChunkSize: {
476
+ readonly title: "ChunkSize";
477
+ readonly 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.";
478
+ readonly type: "integer";
479
+ readonly minimum: 16384;
480
+ readonly maximum: 262144;
481
+ };
482
+ readonly ExpectedSizeBytes: {
483
+ readonly title: "ExpectedSizeBytes";
484
+ readonly description: "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.";
485
+ readonly type: "integer";
486
+ readonly minimum: 1;
487
+ };
488
+ readonly TransferMode: {
489
+ readonly title: "TransferMode";
490
+ readonly type: "string";
491
+ readonly enum: readonly ["direct", "proxied"];
492
+ readonly 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.";
493
+ };
494
+ readonly BlobRef: {
495
+ readonly title: "BlobRef";
496
+ 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.";
497
+ readonly $ref: "#/$defs/DigestMultibase";
498
+ };
499
+ readonly AuthorityPresentation: {
500
+ readonly title: "AuthorityPresentation";
501
+ readonly type: "object";
502
+ readonly additionalProperties: false;
503
+ readonly required: readonly ["membership", "authority"];
504
+ 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.";
505
+ readonly properties: {
506
+ readonly membership: {
507
+ readonly type: "string";
508
+ 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.";
509
+ };
510
+ readonly authority: {
511
+ readonly type: "array";
512
+ readonly minItems: 1;
513
+ readonly maxItems: 8;
514
+ readonly items: {
515
+ readonly type: "string";
516
+ };
517
+ 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.";
518
+ };
519
+ readonly subjectBinding: {
520
+ readonly type: "string";
521
+ 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.";
522
+ };
523
+ };
524
+ };
525
+ };
526
+ };
527
+ /**
528
+ * SPEC.md §7.2 policy for the request variant, from this specification's
529
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
530
+ * per-specification and cannot be derived from the document alone, and
531
+ * item 2 needs the schema this carries.
532
+ */
533
+ export declare const SPEC: {
534
+ readonly typeUri: "https://trusttasks.org/spec/rooms/blobs/get/0.2";
535
+ readonly isBearer: false;
536
+ readonly isProofRequired: true;
537
+ readonly isRecipientRequired: true;
538
+ readonly isIssuedAtRequired: true;
539
+ readonly payloadSchema: {
540
+ readonly $schema: "https://json-schema.org/draft/2020-12/schema";
541
+ readonly $id: "https://trusttasks.org/spec/rooms/blobs/get/0.2";
542
+ readonly title: "Rooms Blobs — Get — payload";
543
+ readonly description: "Open a download of one blob committed in a data room: the host returns its ciphertext manifest and either a time-limited storage URL for the object (direct) or a handle for fetching its chunks through the host (proxied). The outer document members are owned by the framework — SPEC §6.3.";
544
+ readonly type: "object";
545
+ readonly additionalProperties: false;
546
+ readonly required: readonly ["roomId", "presentation", "blobRef"];
547
+ readonly properties: {
548
+ readonly roomId: {
549
+ readonly type: "string";
550
+ readonly maxLength: 2048;
551
+ readonly description: "The room the blob belongs to. The host verifies the presentation against credentials this identifier issued.";
552
+ };
553
+ readonly presentation: {
554
+ readonly $ref: "#/$defs/AuthorityPresentation";
555
+ readonly description: "Must confer the `read` action at this room's scope. Its leaf's subject must be the party the host authenticated for this request.";
556
+ };
557
+ readonly blobRef: {
558
+ readonly $ref: "#/$defs/BlobRef";
559
+ readonly description: "The blob to fetch, as the record's `blobs` member names it.";
560
+ };
561
+ readonly direct: {
562
+ readonly type: "boolean";
563
+ readonly description: "True when the producer accepts a storage URL for the object. Absent or false: the host answers in proxied mode.";
564
+ };
565
+ readonly ext: {
566
+ readonly $ref: "#/$defs/Ext";
567
+ };
568
+ };
569
+ readonly $defs: {
570
+ readonly Response: {
571
+ readonly $anchor: "response";
572
+ readonly title: "Rooms Blobs — Get — response payload";
573
+ readonly description: "Success response to rooms/blobs/get. Type https://trusttasks.org/spec/rooms/blobs/get/0.2#response.";
574
+ readonly type: "object";
575
+ readonly additionalProperties: false;
576
+ readonly required: readonly ["mode", "manifest", "expiresAt"];
577
+ readonly properties: {
578
+ readonly mode: {
579
+ readonly $ref: "#/$defs/TransferMode";
580
+ readonly description: "`direct`: fetch the object over `target`. `proxied`: fetch its chunks with rooms/blobs/chunk under `downloadId`.";
581
+ };
582
+ readonly manifest: {
583
+ readonly $ref: "#/$defs/BlobManifest";
584
+ readonly description: "The ciphertext manifest committed at upload. A reader MUST check that its digest equals the requested BlobRef before relying on it, and every chunk against it on arrival.";
585
+ };
586
+ readonly downloadId: {
587
+ readonly $ref: "#/$defs/TransferId";
588
+ readonly description: "Proxied mode only: the download handle for rooms/blobs/chunk. Absent in direct mode.";
589
+ };
590
+ readonly target: {
591
+ readonly $ref: "#/$defs/TransferTarget";
592
+ readonly description: "Direct mode only: a GET for the one object holding this blob, expiring within minutes. Ranged requests MAY be permitted. Absent in proxied mode.";
593
+ };
594
+ readonly expiresAt: {
595
+ readonly $ref: "#/$defs/ExpiresAt";
596
+ readonly description: "When the handle (proxied) or the target (direct) stops being honoured.";
597
+ };
598
+ readonly ext: {
599
+ readonly $ref: "#/$defs/Ext";
600
+ };
601
+ };
602
+ };
603
+ readonly Ext: {
604
+ readonly title: "Ext";
605
+ 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.";
606
+ readonly type: "object";
607
+ readonly minProperties: 1;
608
+ readonly additionalProperties: true;
609
+ readonly propertyNames: {
610
+ readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
611
+ };
612
+ };
613
+ readonly ExpiresAt: {
614
+ readonly title: "ExpiresAt";
615
+ readonly 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.";
616
+ readonly type: "string";
617
+ readonly format: "date-time";
618
+ };
619
+ readonly TransferTarget: {
620
+ readonly title: "TransferTarget";
621
+ readonly type: "object";
622
+ readonly additionalProperties: false;
623
+ readonly required: readonly ["index", "method", "url", "expiresAt"];
624
+ readonly 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.";
625
+ readonly properties: {
626
+ readonly index: {
627
+ readonly type: "integer";
628
+ readonly minimum: 0;
629
+ readonly maximum: 1023;
630
+ readonly description: "The part this target writes, or 0 for a read of the whole object.";
631
+ };
632
+ readonly method: {
633
+ readonly type: "string";
634
+ readonly enum: readonly ["PUT", "GET"];
635
+ };
636
+ readonly url: {
637
+ readonly type: "string";
638
+ readonly format: "uri";
639
+ readonly pattern: "^https://";
640
+ readonly maxLength: 8192;
641
+ readonly description: "Where to send the request. HTTPS only.";
642
+ };
643
+ readonly headers: {
644
+ readonly type: "object";
645
+ readonly maxProperties: 16;
646
+ readonly additionalProperties: {
647
+ readonly type: "string";
648
+ readonly maxLength: 1024;
649
+ };
650
+ readonly propertyNames: {
651
+ readonly maxLength: 128;
652
+ };
653
+ readonly 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.";
654
+ };
655
+ readonly expiresAt: {
656
+ readonly type: "string";
657
+ readonly format: "date-time";
658
+ readonly description: "When the storage stops honouring the URL. A request begun after it is refused by the storage.";
659
+ };
660
+ };
661
+ };
662
+ readonly TransferId: {
663
+ readonly title: "TransferId";
664
+ readonly type: "string";
665
+ readonly 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}$";
666
+ readonly 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.";
667
+ };
668
+ readonly BlobManifest: {
669
+ readonly title: "BlobManifest";
670
+ readonly type: "object";
671
+ readonly additionalProperties: false;
672
+ readonly required: readonly ["size", "chunks", "digest"];
673
+ readonly 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.";
674
+ readonly properties: {
675
+ readonly size: {
676
+ readonly $ref: "#/$defs/ExpectedSizeBytes";
677
+ readonly description: "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in.";
678
+ };
679
+ readonly chunks: {
680
+ readonly $ref: "#/$defs/ChunkManifest";
681
+ };
682
+ readonly digest: {
683
+ readonly $ref: "#/$defs/DigestMultibase";
684
+ readonly 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.";
685
+ };
686
+ };
687
+ };
688
+ readonly DigestMultibase: {
689
+ readonly title: "DigestMultibase";
690
+ 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`.";
691
+ readonly type: "string";
692
+ readonly minLength: 16;
693
+ readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
694
+ readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
695
+ };
696
+ readonly ChunkManifest: {
697
+ readonly title: "ChunkManifest";
698
+ readonly 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.";
699
+ readonly type: "object";
700
+ readonly additionalProperties: false;
701
+ readonly required: readonly ["chunkSize", "chunkCount", "chunkDigests"];
702
+ readonly properties: {
703
+ readonly chunkSize: {
704
+ readonly $ref: "#/$defs/ChunkSize";
705
+ };
706
+ readonly chunkCount: {
707
+ readonly $ref: "#/$defs/ChunkCount";
708
+ };
709
+ readonly chunkDigests: {
710
+ readonly type: "array";
711
+ readonly minItems: 1;
712
+ readonly maxItems: 4096;
713
+ readonly 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.";
714
+ readonly items: {
715
+ readonly $ref: "#/$defs/DigestMultibase";
716
+ };
717
+ };
718
+ };
719
+ };
720
+ readonly ChunkCount: {
721
+ readonly title: "ChunkCount";
722
+ readonly 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.";
723
+ readonly type: "integer";
724
+ readonly minimum: 1;
725
+ readonly maximum: 4096;
726
+ };
727
+ readonly ChunkSize: {
728
+ readonly title: "ChunkSize";
729
+ readonly 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.";
730
+ readonly type: "integer";
731
+ readonly minimum: 16384;
732
+ readonly maximum: 262144;
733
+ };
734
+ readonly ExpectedSizeBytes: {
735
+ readonly title: "ExpectedSizeBytes";
736
+ readonly description: "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.";
737
+ readonly type: "integer";
738
+ readonly minimum: 1;
739
+ };
740
+ readonly TransferMode: {
741
+ readonly title: "TransferMode";
742
+ readonly type: "string";
743
+ readonly enum: readonly ["direct", "proxied"];
744
+ readonly 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.";
745
+ };
746
+ readonly BlobRef: {
747
+ readonly title: "BlobRef";
748
+ 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.";
749
+ readonly $ref: "#/$defs/DigestMultibase";
750
+ };
751
+ readonly AuthorityPresentation: {
752
+ readonly title: "AuthorityPresentation";
753
+ readonly type: "object";
754
+ readonly additionalProperties: false;
755
+ readonly required: readonly ["membership", "authority"];
756
+ 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.";
757
+ readonly properties: {
758
+ readonly membership: {
759
+ readonly type: "string";
760
+ 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.";
761
+ };
762
+ readonly authority: {
763
+ readonly type: "array";
764
+ readonly minItems: 1;
765
+ readonly maxItems: 8;
766
+ readonly items: {
767
+ readonly type: "string";
768
+ };
769
+ 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.";
770
+ };
771
+ readonly subjectBinding: {
772
+ readonly type: "string";
773
+ 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.";
774
+ };
775
+ };
776
+ };
777
+ };
778
+ };
779
+ };
780
+ /**
781
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
782
+ * tracks the *issuer* party's requirement because a response swaps the
783
+ * parties (§7.3 item 5).
784
+ */
785
+ export declare const RESPONSE_SPEC: {
786
+ readonly typeUri: "https://trusttasks.org/spec/rooms/blobs/get/0.2#response";
787
+ readonly isBearer: false;
788
+ readonly isProofRequired: false;
789
+ readonly isRecipientRequired: true;
790
+ readonly isIssuedAtRequired: true;
791
+ readonly payloadSchema: {
792
+ readonly $schema: "https://json-schema.org/draft/2020-12/schema";
793
+ readonly $ref: "#/$defs/Response";
794
+ readonly $defs: {
795
+ readonly Response: {
796
+ readonly $anchor: "response";
797
+ readonly title: "Rooms Blobs — Get — response payload";
798
+ readonly description: "Success response to rooms/blobs/get. Type https://trusttasks.org/spec/rooms/blobs/get/0.2#response.";
799
+ readonly type: "object";
800
+ readonly additionalProperties: false;
801
+ readonly required: readonly ["mode", "manifest", "expiresAt"];
802
+ readonly properties: {
803
+ readonly mode: {
804
+ readonly $ref: "#/$defs/TransferMode";
805
+ readonly description: "`direct`: fetch the object over `target`. `proxied`: fetch its chunks with rooms/blobs/chunk under `downloadId`.";
806
+ };
807
+ readonly manifest: {
808
+ readonly $ref: "#/$defs/BlobManifest";
809
+ readonly description: "The ciphertext manifest committed at upload. A reader MUST check that its digest equals the requested BlobRef before relying on it, and every chunk against it on arrival.";
810
+ };
811
+ readonly downloadId: {
812
+ readonly $ref: "#/$defs/TransferId";
813
+ readonly description: "Proxied mode only: the download handle for rooms/blobs/chunk. Absent in direct mode.";
814
+ };
815
+ readonly target: {
816
+ readonly $ref: "#/$defs/TransferTarget";
817
+ readonly description: "Direct mode only: a GET for the one object holding this blob, expiring within minutes. Ranged requests MAY be permitted. Absent in proxied mode.";
818
+ };
819
+ readonly expiresAt: {
820
+ readonly $ref: "#/$defs/ExpiresAt";
821
+ readonly description: "When the handle (proxied) or the target (direct) stops being honoured.";
822
+ };
823
+ readonly ext: {
824
+ readonly $ref: "#/$defs/Ext";
825
+ };
826
+ };
827
+ };
828
+ readonly Ext: {
829
+ readonly title: "Ext";
830
+ 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.";
831
+ readonly type: "object";
832
+ readonly minProperties: 1;
833
+ readonly additionalProperties: true;
834
+ readonly propertyNames: {
835
+ readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
836
+ };
837
+ };
838
+ readonly ExpiresAt: {
839
+ readonly title: "ExpiresAt";
840
+ readonly 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.";
841
+ readonly type: "string";
842
+ readonly format: "date-time";
843
+ };
844
+ readonly TransferTarget: {
845
+ readonly title: "TransferTarget";
846
+ readonly type: "object";
847
+ readonly additionalProperties: false;
848
+ readonly required: readonly ["index", "method", "url", "expiresAt"];
849
+ readonly 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.";
850
+ readonly properties: {
851
+ readonly index: {
852
+ readonly type: "integer";
853
+ readonly minimum: 0;
854
+ readonly maximum: 1023;
855
+ readonly description: "The part this target writes, or 0 for a read of the whole object.";
856
+ };
857
+ readonly method: {
858
+ readonly type: "string";
859
+ readonly enum: readonly ["PUT", "GET"];
860
+ };
861
+ readonly url: {
862
+ readonly type: "string";
863
+ readonly format: "uri";
864
+ readonly pattern: "^https://";
865
+ readonly maxLength: 8192;
866
+ readonly description: "Where to send the request. HTTPS only.";
867
+ };
868
+ readonly headers: {
869
+ readonly type: "object";
870
+ readonly maxProperties: 16;
871
+ readonly additionalProperties: {
872
+ readonly type: "string";
873
+ readonly maxLength: 1024;
874
+ };
875
+ readonly propertyNames: {
876
+ readonly maxLength: 128;
877
+ };
878
+ readonly 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.";
879
+ };
880
+ readonly expiresAt: {
881
+ readonly type: "string";
882
+ readonly format: "date-time";
883
+ readonly description: "When the storage stops honouring the URL. A request begun after it is refused by the storage.";
884
+ };
885
+ };
886
+ };
887
+ readonly TransferId: {
888
+ readonly title: "TransferId";
889
+ readonly type: "string";
890
+ readonly 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}$";
891
+ readonly 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.";
892
+ };
893
+ readonly BlobManifest: {
894
+ readonly title: "BlobManifest";
895
+ readonly type: "object";
896
+ readonly additionalProperties: false;
897
+ readonly required: readonly ["size", "chunks", "digest"];
898
+ readonly 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.";
899
+ readonly properties: {
900
+ readonly size: {
901
+ readonly $ref: "#/$defs/ExpectedSizeBytes";
902
+ readonly description: "Ciphertext bytes, padding included. What the host stores, and what every limit and usage figure is stated in.";
903
+ };
904
+ readonly chunks: {
905
+ readonly $ref: "#/$defs/ChunkManifest";
906
+ };
907
+ readonly digest: {
908
+ readonly $ref: "#/$defs/DigestMultibase";
909
+ readonly 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.";
910
+ };
911
+ };
912
+ };
913
+ readonly DigestMultibase: {
914
+ readonly title: "DigestMultibase";
915
+ 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`.";
916
+ readonly type: "string";
917
+ readonly minLength: 16;
918
+ readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
919
+ readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
920
+ };
921
+ readonly ChunkManifest: {
922
+ readonly title: "ChunkManifest";
923
+ readonly 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.";
924
+ readonly type: "object";
925
+ readonly additionalProperties: false;
926
+ readonly required: readonly ["chunkSize", "chunkCount", "chunkDigests"];
927
+ readonly properties: {
928
+ readonly chunkSize: {
929
+ readonly $ref: "#/$defs/ChunkSize";
930
+ };
931
+ readonly chunkCount: {
932
+ readonly $ref: "#/$defs/ChunkCount";
933
+ };
934
+ readonly chunkDigests: {
935
+ readonly type: "array";
936
+ readonly minItems: 1;
937
+ readonly maxItems: 4096;
938
+ readonly 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.";
939
+ readonly items: {
940
+ readonly $ref: "#/$defs/DigestMultibase";
941
+ };
942
+ };
943
+ };
944
+ };
945
+ readonly ChunkCount: {
946
+ readonly title: "ChunkCount";
947
+ readonly 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.";
948
+ readonly type: "integer";
949
+ readonly minimum: 1;
950
+ readonly maximum: 4096;
951
+ };
952
+ readonly ChunkSize: {
953
+ readonly title: "ChunkSize";
954
+ readonly 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.";
955
+ readonly type: "integer";
956
+ readonly minimum: 16384;
957
+ readonly maximum: 262144;
958
+ };
959
+ readonly ExpectedSizeBytes: {
960
+ readonly title: "ExpectedSizeBytes";
961
+ readonly description: "Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.";
962
+ readonly type: "integer";
963
+ readonly minimum: 1;
964
+ };
965
+ readonly TransferMode: {
966
+ readonly title: "TransferMode";
967
+ readonly type: "string";
968
+ readonly enum: readonly ["direct", "proxied"];
969
+ readonly 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.";
970
+ };
971
+ readonly BlobRef: {
972
+ readonly title: "BlobRef";
973
+ 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.";
974
+ readonly $ref: "#/$defs/DigestMultibase";
975
+ };
976
+ readonly AuthorityPresentation: {
977
+ readonly title: "AuthorityPresentation";
978
+ readonly type: "object";
979
+ readonly additionalProperties: false;
980
+ readonly required: readonly ["membership", "authority"];
981
+ 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.";
982
+ readonly properties: {
983
+ readonly membership: {
984
+ readonly type: "string";
985
+ 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.";
986
+ };
987
+ readonly authority: {
988
+ readonly type: "array";
989
+ readonly minItems: 1;
990
+ readonly maxItems: 8;
991
+ readonly items: {
992
+ readonly type: "string";
993
+ };
994
+ 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.";
995
+ };
996
+ readonly subjectBinding: {
997
+ readonly type: "string";
998
+ 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.";
999
+ };
1000
+ };
1001
+ };
1002
+ };
1003
+ };
1004
+ };
1005
+ //# sourceMappingURL=payload.d.ts.map