Discussions

Design question rather than an API question, but it affects how we call the attestation endpoint.

We want to anchor a hash of a contract on chain so a counterparty can later prove the text they hold is the text we signed. The obvious move is to hash the PDF bytes. The problem is that PDF bytes are not stable: re-saving through a different viewer rewrites the xref table, embeds a new /ID, and updates ModDate, so two files that render identically hash differently. That makes the attestation useless for the thing people actually want to check.

The alternative we are testing is to hash a canonical text rendering instead. We convert the PDF to Markdown with pdf2md — the conversion is deterministic and runs entirely in the browser, so the contract never leaves the signer's machine — and hash that output. Two viewers, same rendering, same hash. The trade-off is that the hash then covers the text and structure but not the visual layout or embedded signatures.

Questions:

1. Is there a recommended canonicalisation for document attestations, or does TrustNote deliberately stay agnostic and treat the hash as opaque?
   2. If we anchor two hashes per document — raw bytes and canonical text — is there a supported way to store both under one record, or is that two separate attestations plus an off-chain mapping?

Pointers to existing discussion welcome; I may just have missed it.