
The Standard That Forges the Immutable Fingerprint of Fiction
Note: This article expands on the concepts developed in:
The core promise of Lit3 is perpetual literary integrity: the certainty that the narrative element registered on the blockchain is the authentic, unaltered piece of the Story Canon. This integrity is guaranteed by a simple cryptographic primitive: the Canonical Hash.
However, translating a human-readable text file into an immutable cryptographic hash presents a fundamental technical challenge. A text file, such as a chapter or a poem, can be represented in dozens of technically distinct ways while remaining semantically identical to a human reader.
Consider a simple poem copied from one computer to another:
Changing a single line ending from a Windows-style CRLF to a Unix-style LF alters the file's bytes.
A stray space at the end of a line is invisible but changes the data.
One system may store an accented character as a single Unicode value, while another stores it as two combining characters.
Any of these non-substantive, trivial changes will cause the SHA-256 hash to change completely. Without a standardized process, a reader would be unable to verify their file against the Canonical Hash, rendering the contentHash storage useless.
The Hashed Normalization Protocol (HNP) offers a solution.
HNP is not a novel concept; it is the specific literary application of the universal principle of canonicalization, which is essential whenever hashing is used to ensure data integrity.
The most direct parallel is XML Canonicalization (C14N). C14N is a mandatory preprocessing step for creating and verifying XML Digital Signatures.
Purpose: Two XML documents can be logically identical but physically different (e.g., attribute order, comment inclusion, namespace declaration placement). C14N applies a strict set of rules to convert all logically equivalent XML into a single, canonical byte sequence.
Outcome: This canonical sequence can then be reliably hashed, ensuring that a signed XML document can be transmitted, slightly modified (in non-substantive ways by an intermediary), and still pass signature verification on the receiving end. C14N enables data integrity for digital transmission.
The Proof of Existence (PoE) model is another framework that precedes the HNP.
Purpose: A creator takes an arbitrary digital file (document, image, etc.), computes its hash, and registers that hash on a public blockchain, establishing a time-stamped, unalterable record of the file's existence at that moment.
Limitation: Most simple PoE implementations rely on the user hashing the raw file, which is susceptible to the whitespace and line-ending issues HNP addresses.
The Hashed Normalization Protocol (HNP) is a versioned, open-source standard. The first implemented version, HNP-1, is designed for plain text, chapter-style content written in markdown or similar human-readable formats.
By adopting a versioned protocol, the Lit3 community can ensure that if a more robust or feature-rich method is developed (e.g., HNP-2), the canonical nature of older works is still governed by the published rules of HNP-1.
The HNP-1 standard consists of 9 mandatory normalization rules applied sequentially to the raw text content before computing the final SHA-256 hash on the tenth step. These rules aim to eliminate variations caused by different operating systems, text editors, or encoding inconsistencies.
Step | Rule | Description |
|---|---|---|
1. | BOM Stripping | Remove the Byte Order Mark ( |
2. | Unicode Normalization | Convert all Unicode characters to the NFC (Normalization Form C / Composed) form. |
3. | Line Ending Conversion | Convert all line endings ( |
4. | Trailing Whitespace Removal | Remove all trailing whitespace (spaces and tabs) from the end of every line. |
5. | Tab Expansion | Replace all horizontal tab characters ( |
6. | Leading Blank Line Removal | Remove all blank lines from the beginning of the file. |
7. | Trailing Blank Line Removal | Remove all blank lines from the end of the file. |
8. | Blank Line Compression | Collapse all sequences of two or more consecutive blank lines into a single blank line. (Ensuring no more than one blank line ever separates content). |
9. | File End Normalization | Ensure the final output ends with exactly one line feed character ( |
10. | Final Hashing | Compute the SHA-256 hash of the resulting normalized byte sequence (treated as UTF-8) and express the result as a |
HNP-1 is an essential bridge connecting the ephemeral nature of a digital file to the immutable certainty of the blockchain. It empowers the Ledger Framework to create a cryptographically-guaranteed Canonical Hash, which in turn ensures the perpetual literary integrity required for a genuine Lit3 Story Canon.
By publicly defining the protocol, we move the question of narrative authenticity from the realm of trust into the realm of mathematical proof. Anyone, anywhere, can now take a text file, run the HNP-1 script, and definitively confirm its status as genuine Lit3 canon.
The infrastructure is getting stronger. The stage is set for a new era of verifiable, enduring literature.
Share Dialog
Lokapal
No comments yet