@readymadeit/mcp 0.0.0-stage → 0.1.0

package/bundle/docs/content/boards/live-radio-cloud-demo-board.md

@@ -0,0 +1,70 @@
+# Live Radio (Cloud Relay)
+
+[Live Radio](./live-radio-demo-board.md), but for listeners anywhere on the
+internet. The microphone stays at home. One stream goes up to a relay in the
+cloud, and the relay passes it on to everyone listening.
+
+## What it does
+
+Press Start and the home machine goes on air through the relay. Share the QR
+code or the player address; whoever opens it hears the microphone about half a
+second late. The home machine needs no open port or public address, and it
+uploads a single stream however many people listen.
+
+## How it works
+
+Two [REST runtimes](../concepts/runtime.md): hkp-rt at home, hkp-node in the
+cloud. The relay follows the home runtime, so what the home runtime produces is
+what the relay is given — [the chain](../concepts/runtime.md#the-chain), as on
+any board. The MP3 frames travel as bytes all the way.
+
+### Home (hkp-rt)
+
+1. [core-input](../services/audio-io.md#core-input) captures the microphone. The
+   audio thread only appends and signals; everything after it runs on the
+   runtime's event loop.
+2. [Audio Encode](../services/audio-encode.md) in `stream` mode: one MP3
+   encoder for the whole broadcast, emitting whole frames. They are the home
+   runtime's result, and go on to the relay.
+
+### Relay (hkp-node)
+
+1. [http-server-subservices](../services/http.md#streaming) declares a `stream`
+   at `/live.mp3` and passes each pass it is given to everyone connected there.
+   Every other request is answered by `onRequest`:
+   - **Player page**, a [Map](../services/map.md) answering with an
+     [answer envelope](../services/http.md#what-a-handler-may-answer-with) whose
+     body names one of the board's [assets](../concepts/assets.md): the script
+     for `/player.js`, the page for anything else. The page and its script are
+     the assets **player** and **player-js** — edit them in the asset view, and
+     the next listener to open the address gets the new version.
+2. **End Of Chain**, a [Stopper](../services/stopper.md): nothing needs to go
+   back.
+
+The relay's address is a mount (`/hosted/<id>`): it stays the same across
+restarts and redeploys and cannot be guessed, and it is all a listener needs.
+
+## The window is part of the path
+
+Runtimes do not dial each other: a result goes from one runtime to whoever runs
+the board, and from there to the next. Here that is this window, on the same
+machine as the home runtime, so the detour costs next to nothing — but the
+board has to stay open while it is on air, and every frame passes through the
+window's main thread. If the uplink stalls while the connection to the relay
+stays open, the frames wait rather than being dropped, and listeners fall behind
+for good. While that connection is closed — before it first opens, or between a
+drop and the reconnect — there is nowhere for them to wait: those frames are
+dropped, and listeners hear a gap. The window's console says how many bytes.
+
+[Live Radio (Cloud, direct)](./live-radio-cloud-direct-demo-board.md) connects
+the home runtime to the relay itself instead, and keeps at most about a second
+waiting: pick it when latency has to stay bounded on a poor uplink, or when the
+window may be busy.
+
+## Try it
+
+1. Open the board in the Readymade app at home — the **Home** runtime names
+   the app's own runtime (`"remote": "embedded"`) — and run hkp-node somewhere
+   reachable. Point the **Relay** runtime's URL at the hkp-node server.
+2. Load the board and press Start.
+3. Share the QR code or the player address.

package/bundle/docs/content/boards/live-radio-cloud-direct-demo-board.md

@@ -0,0 +1,89 @@
+# Live Radio (Cloud, direct)
+
+[Live Radio (Cloud Relay)](./live-radio-cloud-demo-board.md), with the home
+runtime connecting to the relay itself. In the Cloud Relay board the stream
+travels the way every result does, through the window running the board; here
+it goes straight from home to the relay over a WebSocket of its own, which
+keeps at most about a second of audio waiting. On a poor uplink listeners skip
+ahead instead of falling behind, and a busy window cannot hold the stream up.
+The price is a writer, a mount reference and a shared secret.
+
+## What it does
+
+Press Start and the home machine goes on air through the relay. Share the QR
+code or the player address; whoever opens it hears the microphone about half a
+second late. The home machine needs no open port or public address, and it
+uploads a single stream however many people listen.
+
+## How it works
+
+Two [REST runtimes](../concepts/runtime.md): hkp-rt at home, hkp-node in the
+cloud.
+
+### Home (hkp-rt)
+
+1. [core-input](../services/audio-io.md#core-input) captures the microphone. The
+   audio thread only appends and signals; everything after it runs on the
+   runtime's event loop.
+2. [Audio Encode](../services/audio-encode.md) in `stream` mode: one MP3
+   encoder for the whole broadcast, emitting whole frames.
+3. [websocket-writer](../services/websocket.md#websocket-writer) sends each
+   chunk to the relay over a WebSocket it opens itself. Its `url` is
+   `hkp-mount://relay/ingest`, a reference to the relay's reader that the board
+   resolves once the relay has an address. The `Authorization` header carries
+   the key from the secret `radio-ingest`. If the connection drops, it
+   reconnects on its own. About a second of audio waits while it does; anything
+   older is dropped.
+4. **End Of Chain**, a [Stopper](../services/stopper.md): nothing needs to go on
+   to the browser.
+
+### Relay (hkp-node)
+
+1. **Uplink**, a [websocket-reader](../services/websocket.md#on-hkp-node), takes
+   the home runtime's connection, but only with the key `{{secret.radio-ingest}}`,
+   and only one at a time (`exclusive`): a reconnecting home runtime replaces
+   its old connection. Each message it receives is a pass through the services
+   after it.
+2. [http-server-subservices](../services/http.md#streaming) declares a `stream`
+   at `/live.mp3` and passes each pass it is given to everyone connected there.
+   Every other request is answered by `onRequest`:
+   - **Player page**, a [Map](../services/map.md) answering with an
+     [answer envelope](../services/http.md#what-a-handler-may-answer-with) whose
+     body names one of the board's [assets](../concepts/assets.md): the script
+     for `/player.js`, the page for anything else. The page and its script are
+     the assets **player** and **player-js** — edit them in the asset view, and
+     the next listener to open the address gets the new version.
+3. **End Of Chain**, a [Stopper](../services/stopper.md).
+
+From **Radio** on, the relay is the same as in
+[Live Radio (Cloud Relay)](./live-radio-cloud-demo-board.md); only how the
+stream arrives differs.
+
+Both addresses are mounts (`/hosted/<id>`): they stay the same across restarts
+and redeploys and cannot be guessed. The key decides who may broadcast; the
+player address is all a listener needs.
+
+## Latency
+
+Measured on loopback with the relay on hkp-node:
+
+| Listener | Behind live |
+| --- | --- |
+| Chrome, player page | 0.3 s buffered |
+| WebKit (Safari), player page | 0.4–0.5 s buffered |
+
+Add the network: one hop up from home to the relay and one down to the
+listener.
+
+## Try it
+
+1. Open the board in the Readymade app at home — the **Home** runtime names
+   the app's own runtime (`"remote": "embedded"`) — and run hkp-node somewhere
+   reachable. Point the **Relay** runtime's URL at the hkp-node server.
+2. Load the board. When asked, give the secret `radio-ingest` a value; any long
+   random string will do.
+3. Press Start. The uplink dot turns green once the home runtime is connected.
+4. Share the QR code or the player address.
+
+If the relay sits behind a reverse proxy, make sure the proxy passes WebSocket
+upgrades on `/hosted/`. The stream itself asks nginx not to buffer it.

package/bundle/docs/content/boards/live-radio-demo-board.md

@@ -0,0 +1,102 @@
+# Live Radio
+
+Your microphone as a radio station: captured, encoded to MP3 as it arrives, and
+streamed to anyone who opens the URL. Two services do the work, and the
+arrangement between them is what the board is about.
+
+## What it does
+
+Press Start and the board goes on air. Open the stream URL in a browser tab or
+VLC, or scan the QR code with a phone, and you hear the microphone with a delay
+of a fraction of a second plus whatever the player chooses to buffer. Listeners
+can come and go at any time; they all hear the same stream.
+
+## How it works
+
+One [REST runtime](../concepts/runtime.md) on hkp-rt. Nothing passes through the
+browser except the controls.
+
+1. [core-input](../services/audio-io.md#core-input) captures the microphone. Its
+   callback runs on the realtime audio thread and does only two things: it
+   appends the samples to a ring buffer and signals. `deferPropagation` is on,
+   so everything after it runs on the runtime's event loop instead. The ring
+   buffer carries the samples across, so a pass that starts a little late reads
+   everything that arrived in the meantime.
+2. [http-server-subservices](../services/http.md#streaming) declares a `stream`
+   at `/live.mp3`. Its `onProcess` pipeline holds the encoder, so every pass
+   encodes once and the result goes to every listener at once.
+   - [Audio Encode](../services/audio-encode.md) in `stream` mode keeps one MP3
+     encoder alive across all passes. Each pass hands it the new samples and
+     passes on only the frames that are finished, as whole frames, so a
+     listener can join between any two chunks.
+
+   - **Player page**, a [Static](../services/static.md) in `onRequest`, answers
+     every other request with a small web page that plays the stream (see
+     below).
+3. **End Of Chain**, a [Stopper](../services/stopper.md). The endpoint has
+   already written each chunk to its listeners. Without the Stopper, the chunk
+   would also become the runtime's result and be sent to the browser forty
+   times a second, where nothing needs it.
+
+The encoder sits inside the endpoint rather than after the microphone because
+encoding and serving belong together. The outer chain only hands PCM to an
+endpoint, so the microphone could be swapped for any other sound source without
+touching the rest.
+
+## The three threads
+
+- **Audio thread.** Appends and signals, nothing else. No allocation, no locks
+  and no logging, whatever happens downstream.
+- **Event loop.** Encodes, then hands each chunk to every listener's queue.
+  Nothing on this thread waits on the network.
+- **Server thread.** Writes to each connection asynchronously. A listener on a
+  slow connection falls behind on its own. Past `maxQueueBytes` it loses its
+  oldest unsent audio and jumps back near the live edge, so neither the stream
+  nor anyone else waits for it.
+
+## The player page
+
+A browser that opens the `.mp3` directly decides for itself how much to buffer,
+and it never catches up afterwards. Measured on this board:
+
+| Player | Behind live |
+| --- | --- |
+| Chrome, `.mp3` opened directly | 2.3 s |
+| Safari, `.mp3` opened directly | 5.4 s |
+| Chrome, player page | 0.3–0.5 s |
+| Safari (WebKit), player page | 0.4–0.5 s |
+| VLC, default settings | ~1.4 s (`--network-caching=200` brings it down) |
+
+The page fetches the stream itself and passes each piece to the browser's Media
+Source Extensions (`ManagedMediaSource` on iOS) as it arrives. It keeps about
+0.4 s buffered, plays 5% faster when it drifts behind, and jumps only when it
+has fallen more than two seconds behind. Stop closes its connection, so a
+stopped listener is not counted; Listen starts again at the live edge. A browser
+without Media Source Extensions falls back to a plain `<audio>` element.
+
+The page is board content: it sits in the Static's `out` as an
+[answer envelope](../services/http.md#what-a-handler-may-answer-with) and can be
+edited like any other state. It plays `live.mp3` next to wherever it is served,
+so if you rename the stream's `path`, change that name in the page too. To let
+people outside your network listen, see
+[Live Radio (Cloud Relay)](./live-radio-cloud-demo-board.md).
+
+## The facade
+
+A status dot for the endpoint, a listener count, a QR code for the player page,
+the page's address and the raw stream URL (for VLC), both copyable, and
+Start/Stop buttons. Start brings up the endpoint before the
+microphone, so the first samples have somewhere to go; Stop does the reverse.
+
+## Try it
+
+Open the board in the Readymade app. Its runtime names the app's own runtime
+(`"remote": "embedded"`), so there is no address to set and no port that has to
+be free. To run it from the playground in a browser against an hkp-rt you
+started yourself, keep that server under the name `embedded` in *Manage runtime
+servers* — outside the app it is a name like any other. Check the
+microphone's **Channels** in its panel: the encoder is set to `1`, which matches
+a built-in mic. For a two-channel interface, set the encoder's `channels` to `2`. If the device
+will not run at the 48 kHz the board asks for, the board says so when you press
+Start; set the encoder's `sampleRate` to the rate the microphone reports.
+The stream is served on port 8890 on your LAN address.

package/bundle/docs/content/boards/live-radio-members-demo-board.md

@@ -0,0 +1,91 @@
+# Live Radio (Members)
+
+[Live Radio (Cloud, direct)](./live-radio-cloud-direct-demo-board.md), made to
+be deployed and shared. Your microphone is the station; the people you share
+the board with are its listeners, and they are the only ones told where to
+tune in.
+
+## What it does
+
+Deploy the board, add the people who should hear you, and send them the link
+from *Copy link*. Each of them signs in, and is shown the player's address,
+a QR code for a phone, and how many are listening. They open the player and
+tap Listen; you press **Go on air**.
+
+Once deployed, the board runs with nobody watching. The audio goes straight
+from the app to the relay and on to every listener, never through the
+coordinator or a window, so it keeps broadcasting for as long as the Readymade
+app on your machine runs.
+
+## How it works
+
+Two [REST runtimes](../concepts/runtime.md), the same as in
+[Live Radio (Cloud, direct)](./live-radio-cloud-direct-demo-board.md): hkp-rt
+in the app, capturing, encoding and sending; hkp-node in the cloud, taking the
+stream in over **Uplink** and passing it to every listener from **Relay**,
+which also serves the player page from the board's
+[assets](../concepts/assets.md). What is different is when each part runs and
+who is shown what.
+
+**The relay is up for as long as the board runs.** Uplink and Relay are not
+bypassed, so the player's address exists from the moment the board is built
+until it is stopped. Going on air switches only the microphone and the
+writer. Off air, a listener's player stays connected and waits; stopping the
+board takes the relay down with everything else, and a player that finds
+nothing at its address says so instead of retrying.
+
+**The player's address is a [mount](../concepts/mounts.md).** Like every
+mount it is unguessable rather than guarded: whoever holds it can listen. Relay
+names its mount `player` (`mountName`), so the address survives restarts and
+redeploys, and changes only when that name does.
+
+## Who is shown what
+
+The facade has two panels. **Live Radio** is everybody's: the uplink's dot, the
+number listening, the QR code, the player's address — a link, through
+`"href": "{{value}}"` — and the stream's address for VLC. **Station** is kept
+for the owner (`"visibleTo": "owner"`): the uplink's state and errors, and
+**Go on air** / **Go off air**. So is the notice raising the microphone's
+errors.
+
+A member is [sent a projection](../concepts/cloud-boards.md#sharing-a-board-members),
+and what is kept for the owner is left out of it before anything is read from
+it. Of the board, a member is sent Relay's address, stream address and
+listener count, and the writer's status — not the Station panel, not the
+ingest endpoint, not the header carrying `radio-ingest`, and not the
+microphone's errors. Going on air is a configure, which a member is refused
+anyway; they are not offered it.
+
+## Sharing it
+
+1. Deploy the board to a coordinator from the Readymade desktop app (below).
+2. Open it in Cloud Boards and choose **Members**: one entry per person, the
+   address they sign in with and the name you know them by.
+3. Send them the link from *Copy link*. It opens only for somebody on the list.
+4. Press **Go on air**.
+
+The address is the same for everybody, and nothing stops a member passing it
+on. Removing somebody from the list closes their view of the board, but not
+what they remember. To cut them off, move the address: give Relay's
+`mountName` a new value in the playground and deploy again. Every listener is
+disconnected, the old address answers nothing, and everybody still on the list
+is shown the new one when they open the link.
+
+## Try it
+
+- **Deploy from the desktop app.** The Home runtime is the hkp-rt the app
+  embeds (`"remote": "embedded"`). A phone's embedded runtime cannot join a
+  coordinator, and the deploy preflight says so.
+- **The Relay runs on the hkp-node you keep as the remote `node`**, and has to
+  be reachable from wherever your listeners are: the player's address is on
+  that server. If it sits behind a reverse proxy, the proxy has to pass
+  WebSocket upgrades on `/hosted/`.
+- **Give the secret `radio-ingest` a value** when asked; any long random string
+  will do. It is handed to your two runtime servers, not to the coordinator,
+  and they keep it in memory only — after either restarts, deploy again.
+- The encoder's channels must match what the Microphone panel reports under
+  Channels: 1 for a built-in mic, 2 for most interfaces.
+
+Opened in the playground rather than deployed, it is the
+[direct](./live-radio-cloud-direct-demo-board.md) board with its relay always
+up: you are its owner, and see both panels.

package/bundle/docs/content/boards/meeting-poll-browser-demo-board.md

@@ -0,0 +1,45 @@
+# Meeting Poll (Browser)
+
+[Meeting Poll](./meeting-poll-demo-board.md) with the database moved into the
+browser. The same polls, the same rules, the same statements — and nothing to
+install.
+
+## What it does
+
+Call a meeting, put up dates, say which ones work, close the poll when a date
+is settled. Your polls are still there the next time you open the board.
+
+## How it works
+
+One browser runtime, twelve [SQL](../services/sql.md) services. They are the
+other board's services, unchanged: the `sql` service exists in both runtimes
+with one contract, and both runtimes are SQLite, so moving the board meant
+changing the runtime it sits in and nothing else.
+
+In the browser, SQL runs SQLite compiled to WebAssembly and keeps the database
+in this browser's storage. The rules are still the schema's — only the
+organiser puts up dates, a closed poll takes nothing more, a person answers a
+date once — so the database still refuses what the page would not have
+offered, and says why.
+
+## What moving it cost
+
+The team. On hkp-node the tables belong to a server, and every member answers
+from their own device as themselves. Here they belong to this browser, so the
+only person there is to be is whoever is signed in at this screen.
+
+Who is answering is decided by the same statements as on the server: whoever
+is signed in to the app. A browser runs its signed-in person's own runtimes, so
+that person is the board's owner here and both organises and answers. Signed
+out, the poll is drawn but takes no answer. Nothing verifies the account — the
+browser is the person — so what it buys is that the board is the same board on
+both runtimes, not that anybody is kept out.
+
+So this is the version for trying the board. To put a date to a team, run
+[Meeting Poll](./meeting-poll-demo-board.md) on hkp-node, deploy it and share
+it with them.
+
+## Try it
+
+Open it signed in. The schema is created on first run, and the polls are kept
+in the browser's IndexedDB under the database name `meetings`.

package/bundle/docs/content/boards/meeting-poll-demo-board.md

@@ -0,0 +1,121 @@
+# Meeting Poll
+
+Dates for a meeting, answered by everybody it is put to. The board's owner
+calls a meeting and puts up times; everybody else says which ones work for
+them — none, one, or all.
+
+## What it does
+
+A Doodle-shaped poll. Call a meeting, propose dates, collect answers, close the
+poll when a date is settled.
+
+## How it works
+
+One [REST runtime](../concepts/runtime.md#the-servers) on hkp-node. Twelve
+[SQL](../services/sql.md) services: seven that change something and five that
+read it back.
+
+**Actions** — Who is here · Call a meeting · Put up a date · Withdraw a date ·
+Works for me · Take an answer back · Close or reopen
+
+**Queries** — The dates · The meeting · What the owner runs · Dates to
+withdraw · Every meeting
+
+Every tap in the facade enters the same pipeline, and the queries at its end
+re-read what it just changed. There is no separate refresh path and no cached
+copy of the poll in the board, so what you see after an action is what the
+database now says — including any change somebody else made in the meantime.
+
+Which meeting is shown is the one a person last picked, and until they pick
+one, the meeting called last — so somebody opening the board for the first time
+lands on the poll they were sent it for. Answering a date keeps them on its
+meeting, even after a newer one is called. Switching to another is done on
+**Vote** itself, from **Meetings** above the dates — a member is not shown
+**Organise** at all.
+
+## The rules live in the schema
+
+None of them is board logic:
+
+- **That only the owner calls a meeting** — a trigger.
+- **That a date belongs to a meeting, put up by whoever called it** — two triggers.
+- **Whether a closed poll still takes a date or an answer** — two triggers.
+- **That a person answers a date once** — a unique index.
+
+The board therefore never offers something the database would refuse, and when a
+refusal does happen — two people acting at once, a stale page, a client sending
+what the facade would not — the error says *why*, because the constraint that
+fired names itself.
+
+Keeping these in the schema rather than the pipeline is the same argument as in
+[Court Booking](./court-booking-demo-board.md): a check followed by a write has
+a gap between them, and a constraint does not.
+
+## Who is answering, and who organises
+
+Every answer is given in somebody's name, and the board never takes that name
+from the request. The statements use the verified caller directly —
+`$caller_email`, the address the server that verified their sign-in states —
+and there is no "you are" field in the facade or its payloads. Without a
+signed-in caller with a verified address the board shows the poll but takes no
+answers.
+
+What somebody may *do* is read the same way. `$caller_role` is what the person
+is to the board — `owner` or `member` — stated by whoever admitted them
+([SQL: who is calling](../services/sql.md#who-is-calling)). Calling a meeting
+records the caller as its organiser only when that role is `owner`; anybody
+else's call names nobody, and the schema refuses it with *only the board's
+owner can call a meeting*. Putting up dates, withdrawing them and closing the
+poll are then the organiser's, which is the owner.
+
+Others are never shown an address. Each person's name is the one the board's
+member list gives them, recorded by **Who is here** as they come by; a voter
+the list names nothing is *a member*, and the owner, whom their own list need
+not name, is *the organiser*.
+
+## The facade
+
+Two tabs. **Vote** — *Which dates work?* — is what most people ever see: who is
+answering (`{ "$user": "name" }`), the meetings to switch between, the one
+picked and whose it is, and one row per date. **Organise** — *The
+meeting* — is the owner's: the meetings to pick from, then for the one picked,
+putting up a date, closing the poll and withdrawing dates, and calling a new
+meeting. `defaultTab` is Vote, because answering is the
+common case and setting up happens once.
+
+Organise is kept for the owner (`"visibleTo": "owner"` on its tab): deployed
+and shared, the coordinator leaves the tab and its panel out of the facade a
+member is sent, so a member sees Vote alone. Its controls are also drawn from
+rows only the owner is given, because who organises a meeting is the
+database's to decide — **What the owner runs** and **Dates to withdraw** end
+in `WHERE $caller_role = 'owner'`. Neither is what keeps the poll safe: Vote
+reaches the same entry point, which takes any payload, and it is the
+statements behind it that refuse.
+
+## Sharing it with a team
+
+1. Deploy the board to a coordinator.
+2. Open it in Cloud Boards and choose **Members**: one entry per person, the
+   address they sign in with and the name the others should see. Add yourself
+   too if you want to be called something other than *the organiser*.
+3. Open it from Cloud Boards — it opens on its facade — and call a meeting and
+   put up its dates on **Organise**.
+4. Send everybody the link from *Copy link*. It opens only for somebody on the
+   list.
+
+Each member sees the poll from their own side — their answers marked as theirs,
+everybody else's by name. One thing to know: a member's view is redrawn by their
+own actions, so somebody else's answer shows on their next tap rather than at
+once.
+
+## Try it
+
+Needs a signed-in account and an hkp-node kept under the name `node` in
+*Manage runtime servers*. Opened in the playground you are the board's owner:
+call a meeting on **Organise** to start. The schema is created on first run, in
+a database of its own (`meetings`) — the board's earlier `meeting-poll`
+database is left as it was, and its polls are not carried over. They named
+people by whatever was typed rather than by a verified address, so not one of
+them would match a caller; and since the schema only creates what is missing,
+opened on the old database it would have kept the old tables and rules beside
+the new ones.

package/bundle/docs/content/boards/mounted-endpoint-demo-board-hkp-rt.md

@@ -0,0 +1,50 @@
+# Mounted Endpoint (hkp-rt)
+
+Two runtimes on the same C++ server, one hosting an HTTP endpoint and the other
+calling it — without either one knowing the address in advance. This is what a
+[mount](../concepts/mounts.md) is for.
+
+## What it does
+
+Every five seconds the caller requests `/hello` from an endpoint hosted by the
+other runtime, and the reply appears in a monitor.
+
+## How it works
+
+Two [REST runtimes](../concepts/runtime.md#the-servers), both on the hkp-rt
+the Readymade app embeds, named as `"remote": "embedded"`.
+
+### Endpoint
+
+1. **Echo Endpoint**, an `http-server-subservices` in `process_on_session` mode,
+   binds no port. Its runtime gives it a path on the server's own listener and
+   publishes the resulting address in its state as `__hkpMount`. Its nested
+   pipeline — a single [Map](../services/map.md) — is what answers the caller.
+2. **End Of Chain**, a [Stopper](../services/stopper.md). The nested pipeline
+   already answered the HTTP request; letting the value continue down the outer
+   chain would be a second, meaningless run.
+
+### Caller
+
+1. **Every 5 seconds**, a [Timer](../services/timer.md).
+2. **Call The Endpoint**, an [HTTP client](../services/http.md), whose `url` is
+   `hkp-mount://endpoint-node/echo-server` — a *reference to the service*, not
+   an address.
+3. **Response**, a [Monitor](../services/monitor.md).
+
+## The point
+
+The endpoint's address is assigned when the board loads, so it cannot be written
+into the board. Rather than hard-coding one, the caller names the service that
+owns it, and the board's [coordinator](../concepts/coordinator.md) resolves that
+reference into a real address — handing it over in a separate field so the board
+still says what it *meant* when you save it again.
+
+Runtime ids are namespaced per user, so `endpoint-node` here never collides with
+somebody else's runtime of the same name on the same server.
+
+## Try it
+
+Open it in the Readymade app, whose own runtime both of them name. The browser
+variant of the same idea is `mounted-endpoint-demo-board.json`, on the
+[Mounts](../concepts/mounts.md) page.