# 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](/spec/) 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](/#status) says so, and will change only when it happens.

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

1

## [The reference application](https://github.com/OpenYacht/openyacht-reference-app-php)

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](/spec/conformance-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](https://github.com/OpenYacht/openyacht-reference-app-php) [README · SETUP · DEPLOYMENT](https://github.com/OpenYacht/openyacht-reference-app-php#readme)

2

## [The WordPress plugin](https://github.com/OpenYacht/openyacht-wordpress)

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](https://github.com/OpenYacht/openyacht-wordpress) [RELEASES](https://github.com/OpenYacht/openyacht-wordpress/releases) [github.com/OpenYacht/openyacht-storage-r2](https://github.com/OpenYacht/openyacht-storage-r2)

3

## 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](/spec/), prove your signing against the [test vectors](/spec/signing-test-vectors/), and self-certify against the [conformance checklist](/spec/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](https://github.com/OpenYacht/protocol/issues/new/choose), or write to [hello@openyacht.org](mailto:hello@openyacht.org?subject=OpenYacht%20implementation) — and [bend a badge on](/brand/) if you fly it.
