0.7.0

The partnership request the protocol describes, and push subscriptions.

Schema v10: new columns on the partners table and a push delivery queue table. The wire gains the optional subscriptions endpoints and features.subscriptions in capabilities only when the new setting is on.

• Adding a partner now introduces this site to it with a signed partnership request carrying a message and a contact email (both editable on the add form, with sensible defaults), so the partnership shows up on their side, with who is asking and why, before any sync poll happens to arrive. Nodes without the endpoint are probed with a signed listings read instead. The result is reported as delivered, already verified, blocked or not delivered; a Send/Resend partnership request row action and wp openyacht partner introduce re-send it.
• Received partnership requests are stored on the partner row and shown under the domain on the Partners screen, next to Approve, and included in the first-contact email; a partner already known here that sends one gets its own email. The endpoint no longer rejects a request missing the message or contact after already registering the sender.
• Push subscriptions (optional protocol feature): with "Offer push subscriptions" on in Settings, verified partners can register a callback and receive every change as a signed POST instead of waiting for their next poll; deliveries retry with exponential backoff for up to 24 hours from wp-cron, so the setting needs a real system cron. On the consumer side, "Subscribe to pushes" on the Partners screen (or wp openyacht partner subscribe) registers this site's inbox with a partner that offers the feature; subscribed partners are polled once a day to reconcile. wp openyacht push list and wp openyacht push deliver inspect and run the delivery queue.
• Unknown HTTP methods on the federation endpoints answer 405 with an Allow header instead of 404.
• Internal: a listing's visibility events are recorded only after the audience change they describe has been applied.

0.6.0

Partner lifecycle fixes, the charter follow-ups from the reference-app port review, and a builder registry refresh. No database change; the wire changes only for charter listings and for the capabilities document.

• A node can no longer partner with itself. The site's own identity domain is refused on the Partners screen, in wp openyacht partner add, and for an inbound request claiming to be this site, which previously could have been auto-registered as a provisional self-partner.
• New Remove action for a partner nothing has been received from, on the Partners screen and as wp openyacht partner remove. It is the undo for a mistaken add: once listings have arrived the partner row is their provenance record, and the partnership ends by blocking as before.
• A partner that has not approved this site yet no longer counts as a sync failure. Polling it used to trigger the failure backoff, so approval on their side could go unnoticed for hours; polls now continue hourly and the Sync now action, the CLI and the Activity log say the partner is awaiting approval.
• The capabilities document advertises charter_listings: true. The node has served charter listings with a charter block since 0.4.0; the flag describes the schema support, not the inventory.
• Charter listings on the wire: charter.rates is withheld for partners without the pricing field group, and price history is never emitted for charter listings.
• A charter payload sent to the wire-shaped ingest was stored as a sale listing; the type now follows the payload. Editing a charter listing validated it against the sale branch of the schema; the revision is pinned to the stored type.
• Synced-listings screens: a charter rate card mixing currencies shows the first currency's range instead of a mislabelled blend, daily rates read "/ day", and the preview page shows a dash instead of a stray placeholder when a listing has no price.
• Vendored builder registry updated to 2026.09.0: 23 yards added (Admiral Marine, Aegean Yachts, Anastassiades & Tsortanides, Bruckmann, CH Marine, Fjord, Italcraft, MetalCraft, New England Boatworks, Novurania, Outer Reef Yachts, Palm Beach Motor Yachts, Pendennis, Rand, Rayburn Custom Yachts, Royal Hakvoort, Timmerman, Tureddi, Vitruvius Yachts, Walker Bay, Westship, Wicks Bros., Wider) and the country filled in on 22 existing entries. The builder picker offers the new yards and incoming payloads carrying their slugs now validate; existing listings are untouched until next saved.

0.5.1

Maintenance release working through a third-party plugin audit of 0.5.0, plus the plugin's adoption of the OpenYacht brand assets. No wire or database change — upgrading is a straight plugin update.

From the audit

The audit returned roughly 1,500 rows, almost all tooling noise: prepared queries flagged for their interpolated table name, nonce warnings on read-only screens, base64 in key handling, vendor code. Those were reviewed and are correct as written. The genuine items, all hygiene:

• readme.txt in the standard WordPress format, with the changelog reconstructed back to 0.1.0. The build now refuses to run when its Stable tag disagrees with the plugin version.
• Direct-access guards in every source file.
• Accessibility: the list screens' search fields carry screen-reader labels, and each listings row checkbox is labelled with the listing name.
• translators: comments on the placeholder strings that lacked them.
• Leaner zip: composer.json and the dependencies' README, CHANGELOG and SECURITY files are no longer shipped. License and notice files stay.

House colours

• The admin menu now carries the OpenYacht mark — signal flags Oscar over Yankee on a halyard — in the small-size cut from openyacht.org/brand, tinted to your admin colour scheme like core's own icons.
• The Updates screen and the plugin's "View details" modal show the OpenYacht icon and banner. Both ship inside the plugin, so wp-admin fetches nothing from a third party.

0.5.0

Curated-partner sharing

A new per-partner sharing scope on the Partners screen: standard (unchanged — receives every listing shared with everyone, plus anything selected for it) or curated — a partner that receives only listings explicitly selected for it, directly or via a group. Built for yacht-show organisers, trials, and press feeds.

• Explicit selections are now additive: they share a listing with the selected partner under any audience except "no one", so an everyone-audience listing can also reach a curated partner without changing what any other partner sees. Standard partners behave exactly as before.
• Flipping a partner's scope replays through the visibility event log: narrowing tombstones the listings the partner saw only via "everyone", widening resurfaces them — on the partner's next poll, with no listing content churn.
• Curated partners get a per-type shared-listings picker on their sharing screen (sale and charter separately — the twins carry different price information), with select-all, group-derived shares shown with their provenance, and a hint when a shared vessel's sale/charter twin exists unshared.
• Selecting listings on the listing editor's audience picker is unchanged; audience changes now preserve the partner selection when moving to "everyone" and when temporarily hiding a listing.
• Schema v8: sharing_scope column on partners, defaulting every existing partner to standard (no behaviour change on upgrade). No wire or protocol change; hidden listings still dereference as NOT_FOUND.

Federation security hardening

This release also carries the fixes from the federation security review: TOFU key pinning is armed at first contact (and established on approve for pre-existing partners), plus the further verifier and partner-lifecycle hardenings from that review.

0.4.5

Makes upgraded nodes re-deliver listings whose wire representation changed, so the 0.4.4 gallery/layout thumbnails reach partners immediately instead of waiting for each listing's next edit.

• New rule for data migrations: when an upgrade changes what a listing serves on the wire, the migration stamps federation_updated_at for the affected listings — that column is the wire updated_at and the sync cursor (API-4), so partners re-sync exactly the listings that changed.
• Applied retroactively to the thumbnail change: on update, every listing with gallery or layout media is stamped — including on nodes that already took the 0.4.4 migration before this rule existed.
• Expect one burst of updates on partner nodes after upgrading; subsequent syncs return to normal incremental behavior.

0.4.4

Adopts the OpenYacht protocol amendment that widens the thumbnail exception to gallery and layout images (new conformance rule LS-16).

• Listings now serve an authority-hosted thumbnail_url for every gallery and layout image — generated from the media library at save time, or null when no rendition smaller than the original exists.
• Existing listings are backfilled automatically on update (schema v6). The backfill doesn't bump updated_at, so partners pick the thumbnails up with each listing's next natural edit rather than a forced full re-sync.
• The Synced Listings preview now shows a gallery grid from the partner's own thumbnails before import — curation no longer needs the images cached first, and full-resolution originals are never hotlinked into the grid (click a tile to view one full size).
• Publishing through the ingest API without the new key remains valid: it is stored and served as null, the correct wire value for "no small rendition".
• Vendored listing schema updated to match the amended protocol.

0.4.3

Adds a Sync now row action to the Partners screen, so you can pull a partner's listings on demand instead of waiting for the hourly sync.

• Available for every non-blocked partner, next to Block and Refresh keys.
• Ignores the failure backoff: clicking it on a partner that has been failing retries immediately, and any error is shown in full on the screen instead of only in the Activity log.
• A successful sync reports what changed: listings created, updated, and tombstoned.
• Manual syncs don't reset the scheduled-sync watchdog, so a site whose wp-cron is asleep still gets warned about it.

Partnering carries no obligation to import — this is the first step toward finer control over what you consume from each partner.

0.4.2

Fixes the invisible Approve link on the Partners screen.

WordPress core CSS globally hides row actions whose key is approve (a rule meant for the comments list, where Approve only shows on unapproved rows). The partner approval action was registered under that key, so provisional partners had no visible way to be approved. The action is now registered as approve_partner; behavior and the form handler are unchanged.

No other changes since 0.4.1.

0.4.1

A small operational release: the two public federation documents become cacheable, and the README picks up the object-cache recommendation that node operators should act on.

/.well-known/openyacht and /openyacht/v1/capabilities now send Cache-Control: public — five minutes for the discovery document, an hour for capabilities. Both are unsigned and byte-identical for every caller, so there was never a reason to serve them with no-store.

The discovery document deliberately gets minutes rather than the 24 hours the protocol recommends consumers hold it for. That 24 hours is an application-layer cache the consumer controls and can bypass on a signature failure to pick up rotated keys; a CDN or proxy honouring our max-age is one they cannot. Key-rotation recovery is worth far more than the handful of origin hits saved on an endpoint that only sees partner adds and throttled refetches. Capabilities gets the longer hour: it carries no keys, and a consumer that briefly misses a feature flag degrades gracefully by design.

Everything else stays uncacheable, on purpose. /openyacht/v1/listings is filtered per partner — a shared cache entry would hand one partner another partner's view — and health checks and error responses must stay fresh. If you run a CDN or page cache in front of this site, leave the federation paths uncached.

A persistent object cache is now a documented recommendation. Every verified inbound request bumps that partner's rate-limit counter, and without Redis or Memcached that counter is two wp_options writes per request, on top of the audit row the request already logs. The cost scales directly with how hard your partners poll, and no page cache can absorb it, because the surface it protects is per-partner. Nothing breaks without one — this is a scaling recommendation, not a conformance requirement — but it is the first thing worth fixing on a busy node. See "Use a persistent object cache" in the README.

No database changes and no configuration changes: upgrading is a straight plugin update.

0.4.0

Charter arrives. This release makes the node fully charter-aware on both sides of the federation:

Charter listings sync and browse. Synced charter listings from partners are stored, browsed, and previewed exactly like sale listings — with their own admin screens. The OpenYacht menu now separates the two inventories the way real brokerage sites do: Sale Listings, Charter Listings, Synced Sale, and Synced Charter are each their own page, so lists are never mixed and navigating into a listing and back keeps your place. Charter listings show their weekly rate range wherever a price is displayed (charter has no asking price by design — its pricing is the seasonal rate block).

Charter authoring begins. New listings choose their type — for sale or for charter — at creation (the type is part of the listing's identity and never changes afterwards). Charter listings serialize to the wire with the schema's type rules honored: a charter block and a null asking price. Authoring the charter details themselves (rates, operating areas, crew) comes in a later release; until then an own charter listing serves an empty but valid charter block.

Two new public hooks for display layers and bridges: openyacht_copy_media_cached fires the moment a synced copy's images finish caching (copy events fire before the background fetch, so this is the first moment renditions exist to render), and openyacht_copy_selection_changed fires when a listing is imported or removed from import.

Also: the admin menu carries the OpenYacht yacht mark instead of a stock icon, and the browsing screens' filter rows sit on their own line.