Is a hash chain the same as blockchain?

Related but not the same. A blockchain is a hash chain plus a distributed consensus mechanism — many machines agreeing on the same chain. A simple hash chain runs on one platform's servers and uses the same cryptographic linking, without the distributed consensus. For co-parent communication, the distributed consensus is overkill — what matters is that the record is verifiably intact, not that ten thousand machines agree about it.

Can a hash chain be faked or forged?

Forging a hash chain would require either breaking the SHA-256 cryptographic function (no known way to do this) or having access to the platform's database to rewrite the entire chain from the alteration point forward. With sound platform-level access controls, neither is practical. The chain's integrity depends on the cryptography (which is solid) and the platform's database security (which is operational).

How do courts verify a hash chain?

They generally don't need to. The hash chain's purpose is to make tampering detectable, which raises the cost of any 'the messages were edited' challenge to the level where it is rarely worth raising. If a court does want verification, the platform can produce the chain values, and an expert can recompute them to confirm integrity. In practice this is reserved for high-stakes matters; for routine family-law use, the platform's representation that the chain is intact is sufficient.

A cryptographic hash function that produces a 256-bit fingerprint from any input. The same input always produces the same fingerprint; different inputs always produce different fingerprints (in practice — the theoretical collision rate is astronomically small). It is the same function used by Bitcoin and most secure-software hashing. Reliable, well-studied, free to use.

Does It's In Writing use a hash chain?

Yes. Every message stores both its own hash (a SHA-256 of the previous hash plus the message body and timestamp) and the previous message's hash. The first message in a connection uses a genesis hash derived from the connection ID. Change any historical message and the chain breaks at that point. The chain values appear in the PDF export so the integrity is visible.

Can I verify the chain myself?

Yes — although for ordinary use you don't need to. The Court tier (planned, not yet shipped) will include 'the Verifier' — an open-source standalone tool that takes a PDF export and confirms the hash chain is intact. For now the chain values are visible in the export and the integrity is platform-attested.

What if the platform itself is compromised?

If the platform's database is fully compromised an attacker could in principle rewrite history — but they would have to recompute every hash from the alteration point forward. The cryptographic chaining doesn't fully solve database-compromise risk; it makes it loud rather than silent. Sound platform security (database access controls, append-only design, audit logs, off-site backups) is what handles the rest. Tamper-resistance is a stack, not a single feature.

What is a hash chain? Why courts care about tamper-proof messaging

If you have read about co-parent communication apps and seen phrases like "tamper-proof", "immutable", or "hash-chained record", you might be wondering what they actually mean. The marketing language is opaque; the underlying mechanism is genuinely interesting and important.

This is a plain-English explanation of how hash chains work, why they matter for evidentiary record-keeping, and what they do and don't protect against. I built It's In Writing using a hash chain as the core integrity mechanism, so the description below reflects how the technique actually gets used in practice — not just textbook theory.

The problem hash chains solve

Imagine a messaging platform that just stores messages in an ordinary database table. The table has columns for sender, recipient, body, and timestamp. Every message is a row.

The problem with this design, for evidentiary use, is that database tables are mutable. An administrator with database access (or an attacker who has compromised the platform) can run a SQL UPDATE statement and change "I'll pick up the kids on Saturday" to "I'll pick up the kids on Sunday." The change is silent. There is no fingerprint of what was there before. Once the alteration is made, the record reads as if Saturday was never said.

For ordinary platforms — Slack, WhatsApp, even most email — this is not a meaningful issue. The threat model is different.

For co-parent communication that may end up in front of a judge, it is the entire problem. The record's value depends on its integrity. If the integrity can be silently compromised, the record cannot be trusted.

How a hash chain works

A hash chain solves this by linking each message to the one before it using a cryptographic fingerprint.

Each message stores two pieces of information beyond its body and timestamp:

The hash of the previous message. A 64-character SHA-256 fingerprint of the previous message's full content (body, timestamp, prev_hash).
Its own hash. A 64-character SHA-256 fingerprint of its body, timestamp, and the previous-hash field.

So message 2's prev_hash equals message 1's hash. Message 3's prev_hash equals message 2's hash. And so on.

Diagrammatically:

Message 1: body="Pickup at 4pm"   prev_hash=GENESIS    hash=A3F7...
Message 2: body="OK, see you"      prev_hash=A3F7...    hash=C2D4...
Message 3: body="Running late"     prev_hash=C2D4...    hash=E8A1...

The first message uses a "genesis hash" — a fingerprint derived from the conversation's unique ID, so that even the very first message has a verifiable starting point.

Why this is tamper-resistant

Suppose someone tries to alter message 2 — changing "OK, see you" to "OK, see you tomorrow" — to suggest the meeting was for the next day, not the same afternoon.

Message 2's hash is computed from its body. If the body changes, the hash changes — C2D4... becomes some other value, say 9F12.... But message 3's prev_hash field still says C2D4... (the old, correct hash from before the alteration).

Now there is a mismatch: message 3 says "the message before me had hash C2D4..." but the actual message 2 now has hash 9F12.... The chain is broken at message 2.

To fix the chain, you would have to also update message 3's prev_hash to the new value. But that changes message 3's hash — which changes what message 4's prev_hash should be. And so on.

To silently alter one historical message, you would have to recompute every hash from that point forward — every single message. The cost of altering history goes from "trivial" to "every subsequent message must be reconstructed in lockstep."

What this actually buys you for evidentiary use

In practical court terms, the hash chain converts "we have to trust the platform" into "we can verify the record is intact."

If the other party challenges the record's authenticity, the response is no longer "the platform's reputation says it's accurate." It becomes "here is the chain. The chain is intact. Verify it independently if you want."

That shifts the burden. Instead of you proving the record has not been altered, the other party would need to prove that every hash from the disputed message forward has been recomputed (which would require platform-level access and would leave its own forensic traces in the platform's logs).

Most family-court matters never get to this level of forensic challenge. But the availability of mathematical verification, even when it is not used, is what gives the record its weight.

What hash chains don't protect against

Worth being clear-eyed about the limits:

They don't prevent the platform owner from running rogue. A platform with full database access can rewrite the chain. Cryptography is one layer; sound platform security (access controls, append-only design, off-site backups, audit logs) is the other.
They don't protect against deletion of the entire account. If the platform deletes everything, the chain goes with it. Periodic exports to your own storage are still essential.
They don't protect the timestamps from being wrong. The chain confirms message integrity given the timestamp; if the platform's clock is wrong, the timestamps are wrong, even if the chain is intact.
They don't protect against the other party screenshotting and editing. The chain is on the platform. A screenshot copied off the platform and altered is a separate problem — but a screenshot can be checked against the platform record at any time, so the alteration is detectable.

For the threat model that matters in family-law evidence — primarily, the other parent disputing what was said — hash chains are the right tool.

Other systems that use hash chains

Hash chains are not exotic. They are the underlying mechanism in:

Bitcoin and other blockchains. Same technique, plus distributed consensus across many computers.
Git (the version-control system used to manage software). Every commit references the hash of the previous commit. Same idea.
Many secure logging systems in finance, government, and healthcare.
Some email integrity protocols (DKIM, though differently structured).

The technique is mature, well-studied, and uncontroversial. What is novel for co-parent communication is the application — using a hash chain as the storage layer for messages between two parents.

Verifying the chain

For most family-law use, you do not need to manually verify the hash chain. The platform's representation that the chain is intact is sufficient unless someone specifically challenges integrity.

If verification is needed:

Export the full record to PDF.
The PDF should include the hash and prev_hash for each message.
An independent verifier (a script, an expert, or — in our planned Court tier — the open-source Verifier tool) can recompute each hash from its inputs and confirm the chain.

It's In Writing plans to ship the Verifier in the Court tier. The intention is that any party can run the tool against an exported PDF and get a clear, independent confirmation of whether the chain is intact. Not a marketing claim. Maths.

What to look for in a platform

If integrity matters for your use, check that the platform:

Uses a cryptographic hash chain (or equivalent — append-only DB design with role-level INSERT-only permissions is similar in effect).
Stores hashes server-side (not on a phone that could be lost or compromised).
Includes hash values in the PDF export so they are visible and verifiable.
Documents the integrity mechanism transparently rather than treating it as a marketing claim.

OFW and Talking Parents both use platform-level integrity mechanisms (their exact implementations are not publicly documented in detail). It's In Writing publishes the hash chain design openly because we think transparency about integrity is itself an integrity feature. If you cannot inspect how the platform protects the record, you are taking the integrity claim on faith.

Try It's In Writing

If you want a platform with a published, verifiable hash-chain design, A$39.95 per parent per year, start free. Five messages on signup, no card required.

The record's value is the integrity. Hash chains make that integrity provable rather than asserted. That is the entire point.