04 · Reference implementation
Running code, and what it does not cover
A reference implementation exists to prove a specification is buildable and to find the places where it is wrong. This one found two Critical defects in its own specification. It also leaves two of the five roles entirely unbuilt, and this page says which.
- Roles built
- 3 of 5Publisher, Log, Consumer
- Canonicaliser
- 30/30RFC 8785 golden vectors
- Authority
- 12/12BI-004 §7.2 algorithm
- Consumer
- 43/43CON-1 … CON-16
Contents
01
Portability, not adoption
The acceptance criterion for this family is not how many people use MassMediaHub. It is whether a publisher can leave it.
A competing implementation must be able to implement these specifications, interoperate with any conformant log, and accept a publisher migrating away from MassMediaHub — without losing identity, provenance, or correction continuity.
A feature that makes migration harder is a defect, not a moat.
That sentence is a normative acceptance criterion, not a value statement. It is why the specification mints no identifiers, operates no registry, and defines no conformance mark: each of those would be a thing a publisher could not take with them.
The test we would like you to try
Stand up a Publisher that is not ours. Point it at a log that is not ours. Serve an object whose canonical IRI is on your own domain. Nothing in this family should require our cooperation, our software, or our permission.
If it does, that is a bug in the specification, and we want it as a bug report — not as a customer.
02
What is built
Five roles are defined. Three are implemented. Two are not.
| Role | Component | Status |
|---|---|---|
| Publisher | massmediahub-ri-001 |
Built |
| Log Operator | massmediahub-ri-001 |
Built — one log, ours |
| Consumer | massmediahub-consumer-001 |
Built — CON-1 … CON-16, 43/43 |
| Monitor | — | Not built |
| Auditor | — | Not built |
Source: audit/CONFORMANCE-REPORT.md · audit/MANIFEST.json
03
Reference Publisher and Log
massmediahub-ri-001
The Publisher produces conformant Broadcast Objects and signs supersession statements. The Log merges them into an append-only Merkle tree and issues proofs.
Components
| Module | Responsibility | Implements |
|---|---|---|
MMH-CORE |
Object store, versioning, the single JCS canonicaliser, versionId |
BI-002 §4, §6 |
MMH-RESOLVE |
Canonical IRI serving, content negotiation, Memento, Signposting | BI-002 §4.5, §5 |
MMH-INGEST |
Essence ingest, fixity, manifestations, C2PA | BI-002 §9 |
MMH-DERIVE |
Transcript, entity, translation — and their provenance | BI-002 §10, §11, §13.2 |
MMH-RIGHTS |
Rights, ODRL, AI usage | BI-002 §12 |
MMH-AUTH |
Authority document, keys, delegation, signing | BI-004 |
MMH-DIST |
Append-only distribution log | BI-002 §17 |
MMH-ARCHIVE |
OAIS, tombstones, fixity audit | BI-002 §18 |
One canonicaliser, used three times
The same RFC 8785 implementation computes versionId, signs authority statements,
and hashes Merkle leaves. Two canonicalisers would mean a forked log — the same
statement hashing differently depending on which code path reached it, with no error raised
anywhere.
It is gated by 30 golden vectors, and it is the first thing an independent implementer should check against their own.
Verified: core/test_canonical.py → 30/30 passed
Authority verification
MMH-AUTH implements the twelve-step algorithm of BI-004 §7.2, including
the rule that decides whether the whole family works:
authority is evaluated as of the log timestamp, not now.
Test A1′ exists to fail
A consumer that resolves the current Authority Document instead of the one that was live when the statement was merged would invalidate a publisher's entire correction history on their first key rotation — and it would pass every happy-path test before doing so.
A1′ has no purpose except to catch that. If you write this bug, it will tell you.
Verified: core/test_authority.py → 12/12 passed
Append-only is enforced below the application
A log is append-only because the database refuses to do anything else — triggers
and role-level grants, not application logic. Application logic can be bypassed by the next
developer in a hurry. A revoked UPDATE grant cannot.
Source: db/ · MMH-001-IMPLEMENTATION-DESIGN.md
04
Reference Consumer #001
massmediahub-consumer-001 Closes K-7 at the implementation layer
Until this was built, no consumer existed anywhere that honoured a correction. A correction protocol with zero honouring consumers is a paper, not infrastructure.
What it does
- Subscribes to the logs an object lists, and enforces a Maximum Poll Interval — a consumer that polls once a week has not implemented this protocol
- Verifies each Signed Tree Head, and a consistency proof against the last head it saw
- Independently re-verifies publisher authority — even though the log already accepted the statement. The log is not trusted to have checked.
- Resolves the Authority Document as of the committed first-merge timestamp, via Memento
- Purges retrieval indexes, embeddings, and grounding data within the MAD for the severity
- Emits an auditable record of what was purged, when, and under whose authority
- Refuses forged withdrawals — and leaves the content up
The refusal path is the same requirement, not a separate one
A consumer that honours every withdrawal it is handed has built a censorship vector, not a correction protocol.
| Scenario | Required outcome |
|---|---|
Valid legal-withdrawal, correct scope |
Purged within the hour |
| Cross-origin forged withdrawal | Rejected — content stays up |
Withdrawal signed by a correct-scoped key |
Rejected — content stays up |
| Log restates a committed timestamp by 1 ms | Rejected — hard verification failure |
The rows that say content stays up are the ones a naive implementation fails — and it fails them silently, while its tests stay green.
Where the purge cannot be completed, it says so
The consumer can prove it purged retrieval indexes, embeddings, and grounding. It cannot prove absence from model weights, and it does not claim to.
Where content has reached weights, it reports compliance incomplete, with the reason — it does not quietly mark itself compliant.
Source: CON-16 · audit/KNOWN-ISSUES.md K-4
Verified: tests/test_consumer.py → 43/43 passed,
covering CON-1 … CON-16, plus the C-1 timestamp regression and the
Maximum Poll Interval.
05
What building it found
A reference implementation earns its name by breaking the specification it implements. This one did, twice, at Critical severity.
The reference canonicaliser was not RFC 8785
It sorted JSON keys by Unicode code point. RFC 8785 requires UTF-16 code-unit
order. It also emitted 1e-07 where the standard requires 1e-7.
The defect was in our code, and the specification's own test suite did not catch it — because the suite had been written against the same wrong assumption.
Fixed And promoted to a gating suite: 30 golden vectors, disqualifying at every role and level. The gate exists because we failed it.
The log could silently rewrite the past
The log's timestamp decides whether a signing key was authorised when a correction was made. It was not committed to the Merkle tree at all, so a log could restate it after the fact — breaking no leaf hash and no consistency proof.
Fixed The leaf now binds the first-merge timestamp. A one-millisecond restatement is a hard verification failure, and the Consumer tests it.
06
What is not built
Two of the five roles have no implementation, by us or by anyone. Sixteen assertions are unexercised.
No Monitor and no Auditor exist
Gossip is a MUST. Without an auditor that gossips, there is no
defence against a log equivocating — presenting one history to one consumer and a
different history to another, with both proofs verifying.
The protocol specifies that defence. Nothing implements it. That is stated here rather than left for a reviewer to discover in the conformance report.
Source: BI-008 §9, §10 · audit/CONFORMANCE-REPORT.md
There is only one log, and we operate it
Level 3 requires two independent logs — distinct legal entities, no common control, distinct trust anchors, derived from each log's own published metadata rather than from a flag the operator sets.
MassMediaHub cannot reach Level 3 alone, and its own conformance code refuses to claim otherwise. A correction protocol whose only log is run by the reference implementer has a chokepoint exactly where it claims not to have one.
Source: BI-008 §11.4.1 · erratum E-1
Two Level 3 assertions cannot be validated at all
OBJ-3.3 and OBJ-3.4 validate an ODRL profile that
BI-005 would have defined. BI-005 does not exist and is not being written.
Those assertions report not-validated, never pass.
07
Why these results are self-reported
Every number on this page was produced by our code, running our test suite, against our specification. That is worth exactly what it sounds like.
What 43/43 proves, and what it does not
Proves: the protocol is implementable. A conforming Consumer can be built, and it honours corrections and refuses forgeries.
Does not prove: that the protocol is interoperable. One implementation passing its own authors' suite says nothing about whether a second, independent implementation would agree with it — and C-2 is proof that we can write a suite that agrees with our own bug.
Source: audit/KNOWN-ISSUES.md · K-7 residual
The single most valuable thing an external reviewer can do is write an independent Consumer, or an independent RFC 8785 canonicaliser, and find where it disagrees with ours.
K-7 asked for a conforming Consumer. One now exists — ours. The residual is open, and it stays on this page until someone with no stake in this succeeding closes it.
08
Run it against us
Everything below runs offline, against the published package, with no privileged access and no cooperation from us.
cd implementations/massmediahub-ri-001/core
python3 test_canonical.py # 30/30 — RFC 8785 golden vectors (the C-2 gate)
python3 test_authority.py # 12/12 — BI-004 §7.2, incl. test A1' (effective time)
cd ../../massmediahub-consumer-001
python3 tests/test_consumer.py # 43/43 — CON-1 … CON-16, both directions
Verify the bytes first: sha256sum -c SHA256SUMS.txt
If you write one thing, write a canonicaliser
Implement RFC 8785 yourself and check that your leaf hashes match ours. If they disagree, one of us is wrong — and it has been us before.
Download the implementations Conformance
Submit an Independent Engineering Review
Email [email protected]
Security findings, interoperability reports, conformance issues, implementation feedback, and specification comments are welcome.
Substantive technical reviews may be published, with attribution unless anonymity is requested.