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](/spec/) [Read the honest status](#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 →](/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](/spec/) 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](mailto:hello@openyacht.org?subject=OpenYacht%20spec%20review) AP · ANSWERING PENNANT — "SIGNAL UNDERSTOOD."