specs/rooms/blobs/upload/commit/v0_1/payload library

Classes

Payload
Complete a blob upload: reassemble it, check it against the manifest committed at begin, and store it. The outer document members are owned by the framework — SPEC §6.3.
Response
Success response to rooms/blobs/upload/commit. Type https://trusttasks.org/spec/rooms/blobs/upload/commit/0.1#response.

Constants

payloadSchemaJson → const String
This specification's payload schema, as JSON text.
responsePayloadSchemaJson → const String
As payloadSchemaJson, for the success-response variant.
responseSpec → const SpecPolicy
The SPEC §7.2 policy for the success-response variant.
responseTypeUri → const String
The success-response form of typeUri (SPEC §4.4.1).
spec → const SpecPolicy
The SPEC §7.2 policy for the request variant, taken from this specification's front matter.
typeUri → const String
The Trust Task type URI this library's Payload is carried under.

Typedefs

BlobRef = DigestMultibase
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.
DigestMultibase = String
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. Multihash 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. This 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. Restricted 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.
Ext = Map<String, dynamic>
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.
TransferId = String
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.