Every blob embeds a base envelope, Signed blob:

Each concrete type extends the envelope. It inherits those four fields and pins type to a literal:

change: an append-only document change, linked into a causal DAG by deps. It carries a change/body of ops.

ref: a signed pointer from a space and path to the current head Changes.

profile: an account's name, avatar and description, or an alias.

comment: a threaded comment. Its body is a tree of block/comment blocks.

capability: a delegation of a role (WRITER or AGENT) to a key.

contact: one account's named reference to another.

Open change in the schema explorer. It shows signer, sig and ts as inherited and the rest as added. The Dependents list of blob is exactly these six types.

Any schema that extends Signed blob and pins a type tag is a signed blob type the app can create. The six built-in types do not reserve the envelope. In the schema editor, tick Signed blob type, set the tag (for example Vote), add your fields, and publish the type as a schema-definition page. Its Create button opens the signing form. You fill in only your fields. The app adds signer, ts and sig at signing time with the selected account's key. It publishes the blob with the convention the daemon verifies: sign the canonical CBOR with the signature zeroed. The result is a verifiable blob on the network. The built-in indexer ignores its type, but any app that resolves your schema can trust and render it. Browse any schema, built-in or yours, at /hm/schema/<cid>.

blob/any is the discriminated union of all six types, tagged on type. You can validate a value against "any Hypermedia blob" as one type.

A Change's body is a list of ops. The op schema is itself a union of SetAttributes, MoveBlocks, ReplaceBlock, DeleteBlocks and SetKey. Content is modeled by block and annotation. Both are open maps: known fields plus arbitrary inline attributes. Document metadata is an open struct of known keys (name, summary, icon, cover, layout, …) plus extras.

Document content is made of blocks. The block model needs two things that conflict. Implementations need strict, concrete types so they can dispatch on block.type to type-safe handlers. Documents need openness so a newer client's block type does not make an older client reject the whole document. One validation pass cannot do both, because an open fallback always accepts a malformed known block. So the model provides layers, and each workflow picks one:

The fifteen concrete blocks are block/paragraph, block/heading, block/code, block/math, block/image, block/video, block/file, block/button, block/embed, block/web-embed, block/nostr, block/table, block/table-row, block/table-column and block/query. Each one extends block/base, is closed, and has a type literal and typed attributes.

block/core is the core union of those fifteen. It is strict and rejects any other block.

block is the open block: id, type and arbitrary fields (through any). It is the forward-compatible wire type. A block type this client has no schema for, future or third-party, is still a valid Block, so a document is never rejected because of it. Use block only as the fallback for unknown types. A custom block type of your own uses extension and a union, as shown below.

Adding a block type

// example/app-block: the core, PLUS this app's custom Poll block
{ "anyOf": [ { "type": "hm://hyper.media/block/core" },
             { "type": "hm://hyper.media/example/poll-block" } ] }

Change is generic over its block type

The wire types map onto primitive schemas, wrapped in aliases with plain names:

validate.mjs checks every one of these schemas. It checks that each is a well-formed schema. It also validates real blob-shaped data against them: a Ref, a Capability, a Change with ops, the union, and metadata. Negative cases cover wrong type tags, missing required fields and unknown keys.