One implementation today
Mildport is, today, the only implementation of the import protocol. We would rather state that plainly than let the word “protocol” imply an ecosystem that does not exist yet.
Here is what the word does claim, checkably: the artifact formats are published, versioned, and permissively licensed; verification and license checks never phone home; and nothing below asks you to take our word for anything you cannot fetch.
What is published
Section titled “What is published”Everything needed to read, produce, or verify the protocol artifacts:
- The specification — prose + JSON Schemas for the Signed Import Receipt, the Portable Import Contract, the Benchmark Scorecard, and the error registry and envelope, all under CC BY 4.0.
- The signing scheme — canonical JSON plus detached JWS (ES256), specified
normatively in enough detail to
implement from scratch: both are built from standard primitives (RFC 7515/7797 JWS,
ECDSA P-256, SHA-256,
JSON.stringifysemantics). - The REST surface — the drift-gated OpenAPI 3.1 document, published verbatim.
- The change rules — versioning & breaking changes, including the error-code evolution rules.
- A working verifier you can read and run —
mildport-verify-receipt(MIT, zero dependencies, offline): verifies a signed receipt with nothing but Node.js. Its committed example was signed by the engine itself, so its green test suite doubles as an interoperability proof. The same repository is the forkable mirror of the schemas.
What a second implementation would need — and where it comes from
Section titled “What a second implementation would need — and where it comes from”| Need | Covered by |
|---|---|
| Artifact shapes | The four published JSON Schemas |
| Canonicalization + signature scheme | The receipt spec page (normative, standard primitives) |
| Wire envelope + error semantics | The errors spec page + registry document |
| Route shapes (if implementing the service side) | The OpenAPI document |
| Compatibility expectations | The versioning policy |
We would genuinely like to see one. If you are building an implementation — a verifier, a pre-flight runner, a producer of receipt-shaped evidence from your own pipeline — nothing in the license requires telling us, but we will happily link serious efforts from this page.
What you cannot get from us yet
Section titled “What you cannot get from us yet”Missing pieces, stated so this page cannot oversell:
- No packaged pre-flight checker. Contract minting is a shipped API; the checking half exists as reference code inside Mildport’s own apps, not as a tool you can install. The contract spec is sufficient to build one.
- Key publication covers our cloud only. The managed cloud’s artifact-signing public keys are published (and mirrored in the spec repository); a self-hosted instance’s keys are its operator’s to publish — by design, not omission.
- No public benchmark runs yet, and therefore no published scorecards.
- No conformance program. “Implements the Mildport protocol spec” is a factual claim anyone may make under the license; “Mildport-compatible” as a certified label does not exist today, and the Mildport name and marks remain ours.
Why the engine is not part of the deal
Section titled “Why the engine is not part of the deal”The protocol deliberately covers the contract — what artifacts are and how to check them — and not the mechanism that produces them well: matching, normalization, confidence, calibration. That split is what lets the spec be permissive while the product stays a product. It also means a second implementation competes on quality of judgment, not on access to paperwork — which is the kind of competition a benchmark can referee.
This page is licensed CC BY 4.0 along with the specification.