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. A self-hostable reference implementation is on the roadmap for brokerages without in-house systems.

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: 358 ENTRIES·ED25519-SIGNED REQUESTS·AGPL-3.0 · FREE TO IMPLEMENT·READ THE SPEC →

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.

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.

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.

LATER · ON DECK
FOLDED, NOT YET BENT ON

Reference implementation

An open-source, self-hostable node (AGPL-3.0) for brokerages without in-house systems, so the network stops being a bilateral arrangement.

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.

PROTOCOL & REFERENCE IMPLEMENTATION: 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 hello@openyacht.org

AP · ANSWERING PENNANT — "SIGNAL UNDERSTOOD."