Index

Two Implementations or It Isn't a Standard

· Tom Cranstoun · 6 min read

This is the eighth post in the standards-governance series. The last one ended on change control - who owns the next version. There is a plainer version of the same worry that applies on day one, before any version has had a successor. If a specification has exactly one implementation, it is not really a standard. It is the documentation of that one program, and whoever owns the program owns the rule, no matter how open the document looks.

One implementation is ownership

A specification is a description of intended behaviour. A single implementation is the only behaviour anyone can actually observe. When they are the same project, the words on the page stop being the standard and the code becomes it - including all the places where the code does something the words never quite pinned down. Every ambiguity is resolved in the implementer's favour by default, because there is nothing else to compare against. Control the only implementation and you control what "compliant" means in practice, which is the quiet capture the earlier posts kept finding, arriving by a different door.

The rule the internet runs on

The body that built most of the internet's protocols treats this as non-negotiable. Since 1996, the IETF's standards process has required that a specification show at least two independent and interoperable implementations, built from different code bases, before it can advance. The wording is exacting: a feature that has not been demonstrated in two interoperable implementations is removed from the standard rather than carried on faith. A later clarification spells out what independence means - different people, at different organisations, using different code and libraries. This is the discipline behind the IETF's old motto, quoted earlier in this series: rough consensus and running code. Not running code, singular. Running codes, plural and agreeing.

What the second implementation finds

The reason is practical, not ceremonial. A second team building from the text alone is the only honest test of whether the text says what its author thought it said. Wherever the first implementation relied on an assumption that never made it onto the page - a byte order, a default, an order of operations - the second one diverges, and the gap becomes visible. Interoperability between two independent builds proves the specification is precise enough to be reproduced, which is exactly the property that lets anyone join without permission. A spec only one program can satisfy is a spec that needs that program. A spec two unrelated programs satisfy needs neither.

There is a failure mode on the other side worth naming. When an ecosystem leans on a single implementation even though the standard is open - the long dominance of one cryptography library, and the day a bug in it exposed much of the web at once - the monoculture becomes a single point of failure for everyone downstream. A standard with one implementation carries that fragility by design.

What COG can show, and what it cannot yet

MX is part way through this test, and the part it hasn't passed is the part that counts for most.

The COG specification has two implementations, a JavaScript reference and a second in Rust. They interoperate in the strict sense: a record signed and canonicalised by one is read and checked by the other. Cross-implementation tests confirm both produce byte-identical canonical bytes across the conformance corpus, so a test carries that claim rather than trust.

The second build has already earned its keep. The two disagreed about how a bare date canonicalises, because one language's YAML library returned an object where the other returned a string. The specification gained a rule that makes both emit the same bytes. Catching that is exactly what a second implementation is for, and one alone never would have.

What they aren't is independent. Both were built by us, inside the same organisation, from the same reading of the same text. Different code and different libraries, yes. Different people at different organisations, no.

The specification says as much about itself. Among the reasons it lists for not yet being ready for certified conformance: no independent third-party implementation, and portability claims that stay theoretical until somebody working from the text alone, with no access to its authors, builds one.

So by the standard this post argues for, COG clears the interoperability bar and doesn't clear the independence bar. Redundancy against a single codebase, we have: if the JavaScript implementation vanished tomorrow the specification would survive it, which is the chokepoint argument this series made about hubs. Independence is still outstanding, and I'd rather treat that as an open invitation than a detail to finesse. The conformance suite is the test target, and what this specification still needs is an implementation from outside that passes it.

A floor, not a finish

Two implementations is a floor, and it is worth saying so. Reaching interoperability once does not keep it; every change to the standard reopens the question, which is why the discipline belongs alongside the change-control argument of the last post - each new version has to clear the same bar before it counts as part of the standard. A reference implementation remains useful, a way to settle arguments and onboard newcomers. The danger was never having a reference. It was having only one.

The test

One question to add for anyone weighing whether a standard is real. Is there more than one independent implementation that interoperates, and was at least one of them written from the specification alone? If the honest answer is that everything traces back to a single code base, then whatever you are adopting, you are adopting its owner along with it.

Tom Cranstoun is the founder of the Machine Experience (MX) community and author of the MX book series. He consults on MX strategy through Digital Domain Technologies Ltd.