# Mission: window.postMessage (and MessageChannel)

## Why
As a frontend engineer, you want durable judgment about **cross-context messaging** — iframe ↔ parent, popup ↔ opener, and the private `MessageChannel` pipe — so communication across a `WindowProxy` is a deliberate tool, not “hope `parent.doSomething()` works” or “spin up BroadcastChannel when you only need a one-to-one pipe.”

## Success looks like
- Given a product need, choose among `window.postMessage`, `MessageChannel` / `MessagePort`, BroadcastChannel, a dedicated/shared worker, service-worker clients, and same-context calls
- Explain the model: a **WindowProxy is not a function call**; origin is the address; `targetOrigin` is the delivery stamp; `event.origin` is who actually wrote
- Transfer a port to open a private two-way pipe, and know when that wins over posting on the public mailbox
- Spot deal-breakers early (missing origin checks, `targetOrigin: "*"`, closed ports, clone/transfer cost, treating messages as server truth)
- Defend the choice in a design review with clear “who can talk, who is trusted, what is cloned”

## Constraints
- Frontend-first: browser platform APIs, not a multiplayer architecture or a security-audit course
- Sibling to Web Workers, BroadcastChannel, Structured Clone, and Service Workers: those tracks already *use* `postMessage` / structured clone; this track owns the **window/iframe surface, origin security model, MessageChannel/ports, and when direct postMessage is enough**
- Short interactive lessons; dense facts live in `reference/`
- Decision fluency + light hands-on
- Prefer modern Chromium + Firefox + Safari; note support only where it changes the design default

## Out of scope
- Full security audit / threat-model encyclopedia
- SharedArrayBuffer + Atomics as a first-class path (label only)
- Comlink-style RPC frameworks (may mention later as a pattern on top of ports)
- Re-teaching the structured-clone type matrix or BroadcastChannel pub/sub (other tracks own those)