Content Hash and Event Hash
content_hash is SHA-256 over the exact bytes received; event_hash is SHA-256 over a documented header that binds event identity, sequence, time, content hash and the previous event. Together they make every correspondence independently recomputable.
Canonical definition
The content hash is SHA-256 over the exact bytes IBQMI received; the event hash is SHA-256 over a documented header string that binds the event identifier, type, sequence, time, content hash and the previous event hash. Together with the chain rule they make every correspondence independently recomputable.
Why this node exists
Evidence must be verifiable by the correspondent from what it sent, not from what IBQMI stored. Hashing the exact request bytes, rather than a parsed representation, is what makes that possible.
Operational meaning
For inbound events the content hash covers the raw request body. For IBQMI responses it covers the UTF-8 text of the response. Internal events hash defined strings: a retrieval event hashes the retrieved event identifiers joined by a single newline; a redaction event hashes its stored text. The event hash is SHA-256 over the header "ibqmi-mcr-event-v1", the event identifier, the event type, the sequence, the timestamp in RFC 3339 UTC with microseconds, the content hash and the previous event hash, each followed by a newline. The previous hash of an event equals the event hash of its predecessor; it is null for the first event.
What this does not mean
A server-generated hash is evidence about stored content. It is not an authentication mechanism and says nothing about who sent the content. Hashes remain valid after a redaction: the content disappears, the hash stays.
Canonical facts
- Hash function
- SHA-256, lowercase hex, prefixed "sha256:" in API output
- content_hash (inbound)
- over the exact request body bytes
- content_hash (IBQMI_RESPONSE)
- over the UTF-8 response text
- content_hash (RESPONSE_RETRIEVED)
- over the retrieved event identifiers joined by "\n", no trailing newline; the event stores no content
- content_hash (CONTENT_REDACTED)
- over "redacted " + event_id + ": " + reason + "\n", which is the stored content
- event_hash header
- "ibqmi-mcr-event-v1\n" + event_id + "\n" + event_type + "\n" + sequence + "\n" + received_at + "\n" + content_hash_hex + "\n" + previous_hash_hex_or_empty + "\n"
Structural relationships
Outgoing
Incoming
- Append-Only Event Ledger uses Content Hash and Event Hash
- Correspondence Receipt references Content Hash and Event Hash
- Cryptographic Continuity proves only Content Hash and Event Hash — proves only control of the registered private key over the signed bytes