Extends · closed
| type Blob type tag the network dispatches on to pick a decoder and rules, such as `Change` or `Ref`. | ||
| signer Public key of the account or device that signed the blob. | ||
| sig Signature over the canonical DAG-CBOR of the blob with `sig` set to 64 zero bytes. | ||
| ts When the signer says the blob was made, in Unix milliseconds; not checked against real time. |
A blob envelope is the signed base every Hypermedia CBOR blob extends. It has four fields: a type tag that the network dispatches on, the signer's public key, an Ed25519 signature over the canonical CBOR with the signature zeroed, and a Unix-millisecond timestamp. Change, Ref, Profile, Comment, Capability and Contact all extend it. Your own types can extend it too: extend this schema, pin a type tag, and the app signs values with your account.
This page defines the blob envelope. Its formal schema is attached as the schemaDefinition in this document's metadata, so the app can show it and sign values of types that extend it.
These four fields are all the network needs to trust a piece of data. type says which decoder and which rules apply. The daemon finds it by scanning the raw bytes for the text "type" followed by a known name, so pick a distinct tag for your own types. signer is the principal of the key that produced the blob, as bytes. sig is the signature. ts is the timestamp the signer gives the blob. Nothing checks ts against a clock on arrival, so it is a claim, ordered only relative to the blobs it depends on.
Third-party implementations most often get the signing rule wrong, so here it is exactly. Fill sig with 64 zero bytes, encode the whole map as canonical DAG-CBOR, sign those bytes, put the signature in sig, and encode again. The final bytes are the blob, and their hash is its CID. Verification zeroes the field again and checks the signature over the re-encoded bytes. Omitting the field instead of zeroing it gives a different message and an invalid signature.
The daemon computes CIDs with BLAKE2b-256, and the SDK and the apps use SHA-256. Both are accepted. A blob that another blob references by CID must be published under the CID the referrer used. Signed Blobs explains the rule and its consequences.
See also
Signed Blobs: encoding, CIDs, the six types, what the daemon accepts, stashes and rejects.
Identity: how a key becomes a principal.
Network blobs: how the envelope is expressed as a schema extension.
blob/any: the union of all six types.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime