Sense 34: The Breeze — Lateral Signalling Through the Jinflow Void

Sense 34 · Steady · Last touched 2026-08-20

• last_verified: 2026-07-27

Synced from docs/design/sense_34_the_breeze.md in the engine repo — that’s the source; this page is a build-time mirror.

The Wire blows outward. The Inlet pulls inward. The Breeze blows sideways — along the clicks, through the jinflow void.

A breeze passes through; the leaves decide whether to flutter.

Status: proposed Date: 2026-05-14 Author: the owner + Claude (afternoon conversation, post-Sense 31) Family: completes the directional triptych — see Sense 30 (The Wire — outward) and Sense 31 (The Inlet — inward). Related: the Landscape’s Garden (Sense 42 — The Landscape) was the first user of this pattern — its 3D walk-through (originally Sense 17, folded in) broadcasts navigation intents to other JinDesk tabs.

---

What pulled us in

When one JinDesk tab needs to influence another tab in the same browser — Our House broadcasting “go to this room” so the content tab follows, the Inbox marking “this notification has been read” so the sidebar updates its badge, a bookmark created in one tab appearing immediately in the bookmarks list of another — there is only one mechanism today: BroadcastChannel('jinflow-cathedral'). Born of the pipeline narrative’s 3D walk-through implementation (originally Sense 17, folded into Sense 42), that single ad-hoc channel quietly handles every cross-tab signal we have so far.

The mechanism works. Its shape is unstated. The gaps that follow:

Today	Why it’s a problem
Channel name ties to one source (“Cathedral”)	Tomorrow we add a different sender; what does it name itself?
No formal message schema — just {type, route, tenant, ts} by convention	Each new event type re-invents fields
No statement of policy	New devs can’t tell whether listeners must obey or may ignore
No place to write down “what events exist”	Discovery is by code search, not by reading a doc

If the pattern keeps growing (bookmark sync, theme propagation, tenant switches, debug events), without a Sense to anchor it, signals will either pile onto the same single channel informally or fork into parallel ad-hoc ones. This Sense gives the pattern a name, a contract, and a principle.

---

The Principle

A breeze announces; the receiver decides.

The Breeze is announcement, not command. A publisher says “this happened” — a click landed, a tab switched, a route changed — without prescribing what any listener should do about it. Each subscriber tab weighs the announcement against its own policy and either acts on it or stays still.

Three properties define every breeze event:

Field	Carries
kind	What sort of thing happened (navigate, bookmark, tenant-switch, …)
payload	Minimal context the receiver needs to act on it (route, id, etc.)
origin	Which tab sent it — so receivers can suppress their own echoes

And four things the Breeze deliberately is not:

• Not a command channel. Listeners can ignore any event. A sender that requires receivers to act should use the Wire, not the Breeze.
• Not authoritative. The publisher doesn’t speak for receivers; no one is in charge.
• Not durable. If you weren’t subscribed when it blew, you missed it. There is no log, no replay, no inbox.
• Not authenticated beyond same-origin. The browser’s BroadcastChannel is bounded to one origin; that’s the trust boundary. Cross-origin coordination is the Wire’s job.

---

Where It Sits

Sense	Direction	Metaphor	Mechanism
30 — The Wire	outward (instance → world)	wire, protocol	HTTP + signed JSON
31 — The Inlet	inward (world → engine)	channel, source_system	scripts + DLZ
34 — The Breeze	lateral (peer ↔ peer in same realm)	breeze through the void	BroadcastChannel

The Wire and the Inlet describe how an instance speaks to the outside. The Breeze describes how tabs within a single JinDesk instance coordinate with each other. They are complementary, not redundant. Each one names exactly one direction; together they enumerate the surface across which signal can travel.

Same shape rule applies as the Wire: a named channel and a structured message contract. Different scope: the Wire’s contract crosses origins under identity-and-passes; the Breeze’s contract is bounded to one origin and trusts the browser’s same-origin model as its only authentication.

---

Today’s Concrete Instance

The first (and so far only) user of the Breeze is Our House — the Landscape’s 3D walk-through (Sense 42 — The Landscape, folded in from Sense 17) — broadcasting navigation intents:

// publisher (Our House)
const ch = new BroadcastChannel('jinflow-cathedral'); // ← legacy name
ch.postMessage({ type: 'navigate', route: '/numetrix.inspire/signals', ts: Date.now() });

// subscriber (every [tenant]/+layout.svelte)
ch.onmessage = ({ data }) => {
  if (alreadyOnThatRoute(data.route)) return;     // receiver decides #1
  if (currentPath.endsWith('/our-house')) return;     // receiver decides #2 — host tab (Our House, the 3D walk-through; was /system/pipeline3d pre-rename)
  goto(data.route);
};

The receiver-decides shape is already present in practice: every subscriber today contains at least two short-circuit checks before following an intent (don’t navigate if already there; don’t navigate if I’m the source/host tab). The Sense merely names what the implementation is already doing.

---

What This Lets Fall Away

• Channel-name proliferation. A single canonical channel (jinflow-breeze) carries every lateral signal; the kind field distinguishes them. New signal types don’t need new channels.
• Archaeology to find the cross-tab mechanism. The pattern has a Sense doc; new code references “Breeze” and finds it.
• Echo suppression as a first-class field. origin is part of the message contract, not an ad-hoc workaround in each subscriber.
• A debug surface. Because all lateral signal flows through one named channel, a dev-mode panel (“Wind Watch”) can render the last N events for visibility without instrumenting each sender.

---

What This Does Not Resolve

These are deferred — they belong in implementation, not in the Sense:

• Migration of the legacy channel name. Today’s code uses jinflow-cathedral. Renaming to jinflow-breeze is a transition the implementation handles with a brief overlap period (listen on both; publish to both; eventually drop the old name). Not load- bearing for the Sense.
• TTL on stale events. A navigate intent that arrives 30 seconds late probably shouldn’t fire; the receiver can drop on now - ts > N. Convention, not contract.
• Cross-realm Breeze via the Wire. Could a Wire message in one instance fire a local Breeze in another? Probably yes — that’s the deliberate-mirror property. Deferred until the second use-case surfaces.

---

How this manifests in jinflow

The Breeze blows sideways — lateral browser-to-browser signalling through the jinflow void. When two JinDesks look at the same tenant in the same session and one of them changes something (a save, a navigation, a presentation-mode page-flip), the other notices. Used for shared exploration (two analysts watching the same Findings page) and for presentation mode (a presenter clicks, every viewer’s browser follows).

• Pairs with: Sense 33 — The Bell (the what of the signal) · Sense 35 — The Drift (server-to-browser; the Breeze is browser-to-browser)

Status: shipped.

---

Stance

The Wire carries what we ship. The Inlet carries what we receive. The Breeze carries what we notice about each other, in the same room. None of them mistakes itself for the others.

A click in one tab is an event. The Breeze is how that event blows through the room. Other tabs feel it pass and decide for themselves whether to move. The engine is deliberately ignorant of which tab is “in charge” — none is. Each tab is its own leaf.

---

Numerical neighbors: ← Sense 33: The Bell — When the System Notices, the Person Hears · Sense 35: The Drift — Server-to-Browser Ambient System Events →