The protocol, in running code

Three systems implement OpenYacht today. Two are open source, published for anyone to read, run, or lift patterns from. The third is a brokerage's own in-house system with an endpoint added to what it already ran — the case the specification was written for.

They share no code. Each was built from the published drafts and the schemas, and each has exchanged listings with the other two — in development and test. Where two of them disagreed, the specification was the thing at fault, and was amended with a note saying so. None of this is the Phase 1 milestone, which is two independent brokerages federating in production; the status section says so, and will change only when it happens.

AP · ANSWERING PENNANT
AT THE DIP: "SIGNAL SEEN." CLOSE UP: "SIGNAL UNDERSTOOD."

The reference application

LARAVEL · AUTHORITY AND CONSUMER · AGPL-3.0 · PRE-RELEASE

A complete node as a conventional Laravel application, and reference material before it is a product: thin controllers, explicit service classes, and the specification cited in the code at the point each rule is implemented, so a developer — or a coding agent — can see a working federation node and carry the patterns into a system of their own.

It serves its own sale and charter listings with the full wire schema; signs and verifies every request (the signing test vectors pass byte for byte) and rotates keys; polls partners with keyset cursors and tombstones; gates field groups per partner; replays every visibility change through an append-only event log, so unsharing arrives as a tombstone and re-sharing as an ordinary update; and offers push subscriptions in both directions. Its tests are grouped by conformance ID: running one group is the self-certification for that row of the checklist.

Runs on PHP 8.4 with the sodium extension, SQLite by default or MySQL. Not yet there: an import connector for an incumbent feed, an installation wizard, and signed URLs for original media — the pieces between "a working node" and "a brokerage with no dev team is sharing by tomorrow", which is what Phase 2 promises.

github.com/OpenYacht/openyacht-reference-app-php README · SETUP · DEPLOYMENT

The WordPress plugin

WORDPRESS 6.4+ · AUTHORITY AND CONSUMER · AGPL-3.0 · PRE-RELEASE

A full node in one plugin, for the many brokerages whose website already is WordPress. Listings are data, not posts — held in the plugin's own tables, with display a separate concern layered on top — and every candidate is validated against the vendored JSON Schema before it persists.

It authors listings in its own editor with the full media model and the shared feature vocabulary; serves the signed endpoints at the site root; verifies partners over TLS with key pinning; polls their feeds and lets site staff choose which synced listings to import, caching media only for those. Per-listing audiences, partner groups and per-partner field-group grants replay through the same kind of event log as the reference application. Activation refuses a site without HTTPS — running non-conformantly is not an option.

Installable from the release zip; updates are self-hosted from the repository's releases, not wordpress.org. Needs PHP 8.1 or later with sodium, a real cron rather than visit-triggered wp-cron, and ideally a persistent object cache. A companion plugin moves cached partner media into a Cloudflare R2 bucket.

github.com/OpenYacht/openyacht-wordpress RELEASES github.com/OpenYacht/openyacht-storage-r2

An in-house system with an endpoint added

PRODUCTION · AUTHORITY AND CONSUMER · NOT PUBLISHED

The first production node is not a product at all. It is a working brokerage's existing in-house system — never designed for federation — with an OpenYacht endpoint added to what it already runs, serving that brokerage's own central-agency mandates over the protocol since August 2026. The specification's claim about itself is that a competent team can do exactly this in days, without adopting anyone's stack. This node is the evidence.

It is private and stays private; nothing about OpenYacht depends on it being otherwise. It was also the counterparty both open-source nodes were first proven against.

What three of them prove

Independent codebases agree on the wire. The reference application and the plugin were written separately, from the drafts. Everything they exchange is what the schemas and the conformance checklist say it is — and the places they first disagreed are now amendments in the spec, each carrying its note.
Everything a partner needs is discovered live. Keys, endpoints and capabilities come from each node's own domain at /.well-known/openyacht. None of the three has ever needed a registry entry, an account, or anyone's permission to federate with another.
The honest state. Between them, the three have exchanged listings in every pairing, in development and test. That is the answering pennant at the dip: the signal has been seen. Close up — two independent brokerages exchanging listings in production — is the milestone still ahead.

Build your own

The specification is written to be implemented without adopting anyone's stack: an Ed25519 library and an HTTP client are the whole dependency list. Start with the reading order, prove your signing against the test vectors, and self-certify against the conformance checklist. The two open-source nodes are worked examples to read alongside, not libraries to depend on.

The licences are chosen for that: the specification text is CC-BY-4.0; the schemas, the OpenAPI description and the registries are MIT, so they can be vendored verbatim into a proprietary system; the two reference nodes are AGPL-3.0.

An implementation built by someone else belongs on this page as much as these do. Open an issue on the protocol repository, or write to [email protected] — and bend a badge on if you fly it.