K · KILO — I WISH TO COMMUNICATE WITH YOU
International Code of Signals — flown between vessels, no operator in between

Broker to broker. Nothing in the middle.

Exchange central-agency listings directly with your co-brokerage partners — live, licensed, and without the API bill.

OpenYacht is an open federation protocol for yacht brokerages: your listings live on your own infrastructure, under your own domain, and flow outward on your terms. For brokerages without in-house systems, two open-source reference implementations — a self-hostable node and a WordPress plugin — are published, pre-release.

Read the spec Read the honest status

DRAFT v0.1 (2026-08) · PHASE 1 · FIRST PRODUCTION NODE LIVE · NO PARTNERS FEDERATING YET·FEDERATION IDENTITY & SIGNING·LISTING IDENTITY & PROVENANCE·SYNC API·LISTING WIRE SCHEMA·BUILDER REGISTRY SEEDED: 364 ENTRIES·ED25519-SIGNED REQUESTS·SPEC CC-BY-4.0 · SCHEMAS MIT · FREE TO IMPLEMENT·READ THE SPEC →

The same six brokerages, twice

In the same six places, both times. The only difference is where the lines go — and where the truth lives.

The platform model · how listings move today source of truth: the middle

scroll →

Six brokerages and several central systems — most brokerages feed more than one of them. None of them are connected to another, and no such connection is on offer. Listings go in; copies come back on each operator's terms, at each operator's price.

OpenYacht · the same six brokerages source of truth: each brokerage

scroll →

chosen — listings flow both ways available — open to either firm, taken by neither

Every pair of brokerages can connect, and no one grants them permission to — that is the faint web. Six of those links are live. A, D, E and F work as a group; B and C share with each other and with nobody else, and for the two of them that is a complete network. Sharing is per-partner and one hop: D holds E's listings, never A's.

The code, entry by entry

An open federation protocol for yacht brokerages to hold their own listing data and share it peer-to-peer with the partners they choose. The protocol is the product — a brokerage with an in-house platform adds an OpenYacht endpoint to what it already runs.

HOUSE FLAG
A VESSEL WEARS HER OWNER'S COLOURS

Your listings, your server, your domain.

Listings live on the brokerage's own infrastructure and flow outward on its terms: to its website, CRM, AI tooling, and chosen partners. A node's identity is its domain: keys are published at /.well-known/openyacht, every request is signed, and trust is pairwise and human-approved — a person approves the partner, once, and listings then flow automatically.

N · NOVEMBER
"NO."

Nothing in the middle.

No central platform, no gatekeeper to register with, no operator who can raise API prices on your own industry's data. Two brokerages on OpenYacht depend on each other and on nothing else.

C · CHARLIE
"YES; AFFIRMATIVE."

One authoritative source per listing.

Every listing has exactly one writer. Everyone else holds a provenance-tracked copy that updates within 24 hours and dies with the listing. The duplicate/stale-data mess that scrapers try to fix statistically, federation fixes structurally.

L · LIMA
"YOU SHOULD STOP YOUR VESSEL INSTANTLY."

Licensed, not lifted.

Media ships from the authority's own infrastructure with content hashes and machine-readable usage terms: the opposite of scraped, watermarked images circulating in stale brochures.

Useful at two nodes: no network-effect threshold. The first connection between two co-brokering firms already delivers live inventory, correct prices, licensed images.

On the wire

Written to be handed to another brokerage's dev team cold. Design goals, in order:

Simple enough to implement in days an Ed25519 library and an HTTP client; no framework to adopt.
No coordination requirements key rotation, recovery, and discovery work without contacting anyone.
Explicit trust nothing is shared with a partner a human hasn't approved.

1 · A node is its domain

Verifying a partner means fetching keys from their domain over TLS: the same trust anchor as email (DKIM) and ActivityPub. A brokerage's domain is already its business identity.

GET https://meridian.example/.well-known/openyacht

// every federation request is then signed:
GET /openyacht/v1/listings?updated_since=2026-08-19T16:00:00Z
X-OpenYacht-Timestamp: 2026-08-20T09:12:04Z
X-OpenYacht-Signature: base64-ed25519-signature

2 · One poll never misses a removal

updated_since returns everything whose federation-visible state changed, including listings that became invisible to you, which arrive as tombstones. Poll with your last sync time and stale data is structurally impossible.

{
  "data": [
    { "id": "https://meridian.example/openyacht/v1/listings/018f4e2a…",
      "type": "sale", "status": "active",
      "updated_at": "2026-08-19T16:05:00Z",
      "vessel": { "builder": { "name": "Benetti", "slug": "benetti" }, "loa_m": 43.6, … },
      "listing": { "name": "OASIS",
        "price": { "amount": "8500000", "currency": "EUR", "on_application": false }, … }, … },
    { "id": "https://meridian.example/openyacht/v1/listings/018f31c7…",
      "status": "sold", … }  // ← the tombstone you can't miss
  ],
  "meta": { "generated_at": "2026-08-20T09:12:05Z", "protocol_version": "1.0" }
}

3 · Media carries its own licence

Images ship with content hashes and machine-readable usage terms, hi-res gated per partner. Builder names validate against the registry's fixed vocabulary; a slug that isn't in it doesn't exist on the wire.

"media": { "profile": { "url": "https://meridian.example/media/018f4e2a/profile.jpg",
                       "sha256": "d1a4…", … }, "gallery": [ … ] },
"usage": { /* machine-readable terms, defined normatively in the spec */ }

ILLUSTRATIVE EXCHANGE — DOMAINS ARE EXAMPLES AND PAYLOADS ARE ABBREVIATED; FIELD SHAPES FOLLOW THE DRAFT v0.1 WIRE SCHEMA, REBUILT AGAINST REAL FEED EXPORTS AND THE FIELD MODELS OF WORKING IN-HOUSE SYSTEMS.

What flies today

Signal practice is honest about state: a flag at the dip is hoisted but not yet in force; close up, it is. Nothing here flies close up yet.

NOW · AT THE DIP
HOISTED, NOT YET CLOSE UP

Spec published, first node live

Six documents, all Draft v0.1, published here for public technical review — and validated against a first production node: a working brokerage's in-house system serving its own sale mandates over the protocol.

NOW · AT THE DIP
AP · ANSWERING PENNANT — "SIGNAL SEEN"

Reference implementations published

Two open-source nodes (AGPL-3.0): a self-hostable Laravel application and a WordPress plugin, each exchanging listings with the other and with the production node in test. Pre-release, and written to be read — the implementations page says what each one does.

NEXT · BENT ON
P · BLUE PETER — "ABOUT TO PROCEED TO SEA"

Two real nodes

Partners federating: a second independent system exchanging live listings with the production node. A reference consumer has already passed a full cold sync and delta poll against it.

When two independent nodes exchange listings in production, this page will say so — and not before.

Designed against real production systems, by people who run brokerage data infrastructure — not designed in the abstract.

SPECIFICATION TEXT: CC-BY-4.0 · SCHEMAS, OPENAPI & REGISTRIES: MIT · REFERENCE IMPLEMENTATIONS: AGPL-3.0
THE SPECIFICATION IS PUBLIC AND FREE TO IMPLEMENT — NO LICENCE, NO REGISTRATION, NO PERMISSION REQUIRED

I wish to communicate with you.

Reviewing for a brokerage? Building against an in-house system? The spec documents are written to be handed to a dev team cold: your first-meeting questions about identity, authority, mandate changes, and usage terms are answered in the drafts on purpose.

Write to [email protected]

AP · ANSWERING PENNANT — "SIGNAL UNDERSTOOD."