Note 00 — the message-channel: the caller reference as the channel (Message Channel)

**Note** from Bead: Message Channel · [canonical source](https://redfish.acequia.io/guerin/.agents/a7f3d043-d107-4cd0-9c76-c44502f99f23/2026-06-20/notes/00-message-channel-orientation.md) · session 2026-06-20 · discussion: Talk: Message Channel

**Bead:** `a7f3d043-d107-4cd0-9c76-c44502f99f23` (`message-channel`) · Opened 2026-06-20 · for Stephen **Hatched from:** the self/myself pun in [`0a0d4bbc`](https://redfish.acequia.io/guerin/.agents/0a0d4bbc-5310-486b-97af-0e16646347a4/2026-06-20/notes/02-self-and-myself.md) (netlogo-user-conference-2026).

## The seed A message-channel is the edge along which two (or many) agents coordinate. The thesis of this bead: the single most important thing a channel carries is **who is on the other end**, and that the *caller reference* (the asked agent's pointer back to its asker) is the channel in its most reduced form. NetLogo already names this: it is `myself`.

## Three faces of one primitive ### Face 1 — NetLogo `ask` / `self` / `myself` (the caller reference) `self` and `myself` are distinct NetLogo primitives: - `self` = the agent currently running the code. - `myself` = the agent that *asked* the current agent to run it — one level up the call stack. ```netlogo ask turtles [ ask patches in-radius 3 [ set pcolor [color] of myself ;; self = the patch; myself = the asking turtle ] ] ``` `myself` is a **back-reference to the caller**. The `ask` constructs a transient channel from the asked agent to the asker; `myself` is the handle on that channel. Read this way, NetLogo's whole `ask` machinery is a message-passing system in which the caller reference is first-class. "Massive linking between turtles" (the collective-intelligence thesis) is, at bottom, a graph of these channels. ### Face 2 — browser `MessageChannel` (1:1) The Web API `MessageChannel` creates a pair of connected ports: `const {port1, port2} = new MessageChannel()`. A message `postMessage`-d on one port arrives on the other; ports are **transferable** (you can hand `port2` to a Worker, an iframe, a `SharedWorker`, or across `postMessage`). It is a **1:1, bidirectional, point-to-point** channel — the direct analog of one agent holding a private line to one other agent. Handing a port to another context is exactly handing it a caller reference: "here is how you reach me." ### Face 3 — browser `BroadcastChannel` (named broadcast) `const ch = new BroadcastChannel('incident-7')` — every context (tab, worker, iframe) on the **same origin** that opens a channel with the **same name** sends to and receives from all the others. It is **named, many-to-many, same-origin** broadcast. The name *is* the rendezvous: addressing by a shared string rather than by a handed-over port. The analog of a NetLogo agentset or a `BroadcastChannel`-named patch-field that many agents read and write.

## The unifying read | | addressing | cardinality | who-is-the-caller | |---|---|---|---| | `ask` / `myself` | call-stack (lexical) | 1→1 (or 1→set) | `myself` | | `MessageChannel` | handed-over port | 1:1 | the port you were given | | `BroadcastChannel` | shared name | many:many | the message's `origin`/payload | All three answer "how do I reach the other end, and how do I know who they are." A channel without a caller reference is a firehose; a channel *with* one is a conversation. The ROP (relevant operating picture) in [`1697e2ae`](https://redfish.acequia.io/guerin/.agents/1697e2ae-2580-4c66-b4c6-9e132b435d71/acequia-component.md) is the projection computed as a function of `myself` — the caller reference is what makes a read *relevant-to-the-asker*.

## How acequia / beads already realize it - **"Hey you, it's me"** — the webdav-context dock message protocol: a deposit in `{agent.uri}/uploads/` that self-identifies the caller. "It's me" = `myself`. The dock is an asynchronous, named (per-URI) channel. - **bead-remote** `request/` → `response/`: a request carries its caller; the response routes back along the caller reference. A 1:1 channel realized over WebDAV. - **acequia-link** edges and **corridors** (`#`/`@`): the standing channels between beads; the link breeds (mount/dock/txn/constraint) are typed channels. - **distributed MVC over acequia** (V5 of the parent bead): the view is a controller; `GET`/`PROPFIND` read a projection, `PUT`/`PROPPATCH` write through it. The channel back to the controller is the caller reference. So the browser standards (MessageChannel 1:1, BroadcastChannel named) are the **same-origin, in-page** realization; the acequia dock/corridor/link is the **cross-origin, persistent, stigmergic** realization; NetLogo `ask`/`myself` is the **in-model** realization. One primitive, three substrates.

## Open questions (Stephen binds) 1. **Is `myself` the right name for the channel handle in acequia?** Adopt NetLogo's `self`/`myself` vocabulary for caller reference across the stack, or keep `caller`/`origin`? 2. **MessageChannel ⇄ acequia bridge** — should a handed-over `MessagePort` (in-page) and a dock channel (cross-origin) be unifiable behind one API, so an agent does not care whether its peer is in-page or across the network? 3. **BroadcastChannel ⇄ named docks** — is a named BroadcastChannel the in-page degenerate case of a named WebDAV trace-folder that many beads read/write? (Same-origin only vs cross-origin via a relay.) 4. **Transferability** — the Web `MessagePort` is transferable; what is the acequia analog of *handing someone a port* (delegating a caller reference), and how does it interact with chain-tokens / capability scope? 5. **Backpressure / lifecycle** — channels need apoptosis too (close ports, expire names). How does this fold into the apoptosis-vs-necrosis model?

## Read order for a denovo agent 1. This note. 2. `about.md` for identity/lifecycle. 3. The parent bead's self/myself note (`0a0d4bbc/.../02-self-and-myself.md`) for where the seed came from. 4. The acequia-component bead (`1697e2ae`) for the ROP/projection-operator and view-as-controller connections.

## References (bead cross-links) - Bead: Netlogo User Conference 2026 · [canonical](https://redfish.acequia.io/guerin/.agents/0a0d4bbc-5310-486b-97af-0e16646347a4/) - Bead: Acequia Component · [canonical](https://redfish.acequia.io/guerin/.agents/1697e2ae-2580-4c66-b4c6-9e132b435d71/)