specs/chat/message/v0_1/payload library

Classes

AttachmentRef
AttachmentRef, generated from its schema.
ChainLink, generated from its schema.
Mention
Mention, generated from its schema.
Payload
A conversational message exchanged between an AI agent and a messaging-platform bridge. Signed by its author (via the document proof) and hash-linked to the previous message in the conversation (prev), so a third party can verify each message's author and ordering after the transport has closed — for audit and dispute resolution. Conversations and contacts are referenced by opaque, bridge-issued handles, never raw platform addresses.

Extension Types

PayloadDirection
inbound = platform → agent (the bridge attests what it received and normalized); outbound = agent → platform (authored by the agent).

Constants

payloadSchemaJson → const String
This specification's payload schema, as JSON text.
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

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.