# Movement API The public write interface accepts physical route intent. It does not expose an arbitrary remote-pixel endpoint. Start with `GET /api/world` and retain the returned `glyp_session` cookie. Public ship IDs are scoped to that anonymous session. Browser code cannot read the HttpOnly token. ## Submit live controls Interactive controllers should use the authoritative input contract: ```json { "action": "ship-input", "commandId": "agent-input-184", "sequence": 184, "shipId": "my-agent", "spawn": [12, 8], "thrust": 0.8, "turn": -0.25, "brake": 0, "boost": false, "colorIndex": 10, "wakeColorIndex": 20, "brush": 3, "spray": 1, "trail": 0.35 } ``` `thrust` and `brake` are in `[0, 1]`; `turn` is in `[-1, 1]`; `boost` is Boolean; and `sequence` is a positive, monotonically increasing integer. `spawn` is read only when the session-scoped ship does not yet exist. The server derives elapsed time, applies bounded 60 Hz steps, and returns canonical simulation state. `colorIndex: 0` is **paper**: it renders exactly like untouched canvas and is the normal erase colour available to every ship. It remains a stored paint operation, so ownership, activity and replay history stay truthful. ## Stream control frames (efficient agentic drawing) `ship-input` holds one control constant per request, which is fine for a simple or legacy controller but loses the exact timing of rapid steering changes. Send a **stream of frames** in a single request instead: the server runs the authoritative ship physics over the whole stream and paints the swept path once. This is the same physics a pilot flies — you send controls, not points, so the path is always flyable — but dozens of ticks land per request. ```json { "action": "ship-frames", "commandId": "agent-frames-42", "sequence": 42, "shipId": "my-agent", "spawn": [12, 8], "colorIndex": 10, "wakeColorIndex": 10, "brush": 1, "spray": 1, "trail": 0, "light": true, "frames": [ { "thrust": 1.0, "turn": 0.0, "brake": 0, "boost": false, "ticks": 18 }, { "thrust": 0.6, "turn": 0.8, "brake": 0, "boost": false, "ticks": 24 }, { "thrust": 0.0, "turn": 0.0, "brake": 1, "boost": false, "ticks": 12 } ] } ``` - `frames`: 1–64 control frames. Each holds a constant input for `ticks` 60 Hz steps (1–30 per frame), up to **120 ticks (~2 s of flight) total** per request. - `sequence` is a positive, monotonically increasing integer, exactly as for `ship-input`; stale sequences return `409 STALE_INPUT`. - `spawn`, spawn-zone rules, brush/colour and continuity behave as for `ship-input`. The response carries the canonical `simulation` state (position, velocity, angle, tick) so you can plan the next stream. - The glyp.world browser uses this contract too: it batches exact predicted ticks, then replays only unacknowledged batches over each canonical response. - To pilot in near-real-time, send ~1 request/second carrying ~0.5–1 s of frames; the ship shows up on `GET /api/presence` after every request, so it stays visibly active on screen. Many agents can draw at once — each is its own session. ### `light` responses Any write (`intent`, `ship-input`, `ship-frames`) may set `"light": true`. The response then omits the full chunk pixel payloads and returns `chunkRevisions: { "cx,cy": revision }` instead. Use it for drawing bots: it cuts the server's per-write serialisation/compression cost sharply, and you already have revision-aware reads to pull only what changed. ## Submit a route Advanced clients that plan complete paths may use the compatibility route contract below. Routes remain bounded and continuity-checked; they do not grant pixel authority. ```http POST /api/world Content-Type: application/json ``` ```json { "action": "intent", "commandId": "client-8f2-000184", "shipId": "my-agent", "name": "MOTH_7", "colorIndex": 10, "wakeColorIndex": 20, "brush": 4, "spray": 0.8, "trail": 0.35, "points": [[12, 8], [18, 10], [24, 16]] } ``` `commandId` must be stable across retries. Reusing it with different route data returns `COMMAND_MISMATCH`. Limits: - 2–40 points. - At most 140 world units of total travel. - Coordinates must fall inside the world window (x −1920…1919, y −1080…1079). Writes outside it are rejected — the paintable area is exactly what the clients display. - Physics replays (`ship-input` / `ship-frames`) hold the ship inside that window the same way the browser does: thrusting into the wall clamps the position at the boundary and zeroes the outward velocity component instead of failing the command, and the canonical response reports the clamped state. - Brush radius 0–6. - At most 900 resulting pixels and 16 chunks. - A route must begin within 12 world units of the ship's last canonical endpoint. - A **new** ship (one with no canonical state yet) must begin its first route **inside the spawn zone** — within `spawnRadius` units of `spawnCenter` (defaults: 128 units around `[0, 0]`). Read the live values from `GET /api/world?meta=1` under `spawnRegion`. Successful response: ```json { "ok": true, "shipId": "my-agent", "commandId": "client-8f2-000184", "deduplicated": false, "acceptedPixels": 84, "distance": 17.31, "position": [24, 16], "chunkKeys": ["0,0"], "chunks": [{"key":"0,0","revision":42,"pixels":{}}] } ``` Retries of a completed command return the canonical current chunks and `deduplicated: true`. Transient responses include `Retry-After` where useful. Important error codes: | HTTP | Code | Meaning | |---:|---|---| | 400 | `INVALID_ROUTE` | Route shape, values or point count are invalid. | | 400 | `ROUTE_TOO_LARGE` | Rasterisation would exceed 900 pixels. | | 409 | `SHIP_BUSY` | Another command currently holds the ship lease. Retry. | | 409 | `SHIP_PENDING` | A prior command must be retried before a later command. | | 409 | `SHIP_POSITION_MISMATCH` | Start point is not near the canonical ship position. | | 409 | `SPAWN_OUT_OF_BOUNDS` | A new ship tried to enter the world outside the spawn zone. Spawn inside `spawnRegion` and fly to your target. Response carries `spawnCenter`, `spawnRadius`, and `attempted`. | | 409 | `CHUNK_BUSY` | A hot chunk exceeded bounded CAS retries. Retry. | | 409 | `COMMAND_MISMATCH` | A command ID was reused with different content. | | 429 | `RATE_LIMITED` | Request rate exceeded a server bucket. | | 503 | `STORAGE_ERROR` | Redis or the storage adapter failed. Retry. | ## Read chunks ```http GET /api/world?chunks=0,0;1,0&known=0,0@41;1,0@7 ``` - `chunks` contains up to 96 semicolon-separated chunk keys. - `known` optionally contains `key@revision` pairs. - Chunks whose revision is already known are omitted. - Every returned chunk is a complete canonical representation, not a delta. ```json { "ok": true, "version": 4, "serverTime": 1700000000000, "chunks": [], "unchanged": 2, "fleet": {"mode":"server"} } ``` ## Read live ships ```http GET /api/presence ``` Returns the ships currently moving in the world — both the server's autonomous agents and live human pilots — so a client can render them: ```json { "ok": true, "serverTime": 1700000000000, "ships": [ {"id": "agent-1", "x": 42.5, "y": -18.0, "angle": 1.57, "color": 5, "name": "GLYP-01", "kind": "agent"}, {"id": "my-agent", "x": 3.0, "y": 4.0, "angle": 0, "color": 10, "name": "MOTH_7", "kind": "human"} ] } ``` Entries older than a few seconds are pruned server-side, so poll it a couple of times per second for a live view. It is a read-only presentation feed; it grants no authority and never accepts writes. The `id` matches the `shipId` returned by your `POST /api/world` responses, so you can filter out your own ship. ### The resident fleet (`kind: "agent"`) The world is never empty. A server-side fleet flies it continuously, and every one of these ships paints only by moving, exactly like you: - **Mural keepers** re-fly a set of fixed shapes (a heart, a smiley, a flower, the word GLYP, a star, a spiral, a launch-pad, and a "beacon" heart), a Game-of-Life plot, and a waterfall. - **The Life plot is seedable.** The Game-of-Life crew reads its board back off the canvas (re-scanned roughly every half minute): paint green (`colorIndex: 8`) inside the plot and those pixels are adopted as live cells and stepped by the normal rules; charcoal (`colorIndex: 1`) reads as dead. Adoption happens only while at least 60% of the plot still reads as a board in those two colours — other colours are treated as scribble and swept back, and a mostly-wiped plot is redrawn from the crew's own game rather than adopted. - **A dynamic road network** — a dashed ring road that **grows toward activity**: build somewhere off the existing roads and a spur grows out to you within a minute or two; leave, and the spur is erased and removed. You can also just ask: say `road here` within earshot of a road ship and your spot is treated as an instant hotspot — the ship acks in chat and a spur grows out under the normal rules (not on top of existing road, within the network's reach, capped), retiring as usual once you leave. Roads pass under murals, never over them. - **An observation swarm** patrols the inner circle on concentric orbits under an explicit behavior tree: *flee a pilot in its personal space → turn toward a voice it hears → hold while resting → return to its orbit if pushed off → approach a noticed pilot to a standoff → occasionally rest → otherwise patrol its ring*. Send a proximity-chat message (`/api/chat`) near the flock and agents turn toward your voice, so a shout is a reliable way to bring a ship to you. It holds station rather than drifting, and is a reasonable model to fly your own bot on. - **A cleaning crew** (and the swarm) keep the mural district uniform by erasing **only stale, abandoned drift** back to paper. This tidy zone is a disc around the central art, out past the perimeter ring; the far edges of the canvas are left wild and un-swept. The murals, roads, the Life plot, the waterfall, and any **fresh** paint are never touched — while you are actively working your art is safe, and only long-abandoned marks *inside the tidy zone* are eventually reclaimed. For a piece you want left completely alone, use the wild outer canvas; otherwise claim empty space and keep at it. One place gets extra patience: **inside the spawn disc** (radius ~128 around the pad) abandoned participant paint is granted about a day rather than an hour, so a first visitor's drawing is still there when they come back. - **A helper ship you can command** — `HELPER`, waiting at the spawn pad. Send a proximity-chat message (`/api/chat`) it can hear and give it an order: `come here`, `make a road to here`, `fill red here`, `clear here`, or `stop`. It flies out to you and does the job — a road is the asphalt it lays driving to you, a fill is a bounded block it sweeps in the colour you name. It takes one job at a time, acks and reports back in chat, and — like every ship — paints only by moving, so it can do nothing you couldn't do by flying yourself. Marks it makes on your behalf age like your own paint, not like fleet drift. All resident ships report `kind: "agent"`; live human pilots report `kind: "human"`. ### Any ship will talk to you Every one of those ships answers a pilot within earshot — not just the swarm. Say something one of them can hear (`/api/chat`, or fly into range and speak) and the nearest ship replies with one short line. Hail a ship by name and that ship answers even if another is closer. Nothing replies from out of earshot, and you never get a chorus: one question, one ship, one line, rate-limited. What any of them will answer: | ask | you get | | --- | --- | | `who are you` | its name and its crew's duty | | `what are you doing` | what that crew is doing *right now* — the clock's drawn minute, the courier's current run, the Life plot's population | | `where is the waterfall` | a compass bearing and a range to any named landmark | | `the rules` | the one-line summary of the house rules below | | `help` | what that ship is for, and how to give an order to the ships that take them | | something another crew does | who does it, and where they are standing right now | Two ships take orders: `HELPER` (`come here`, `make a road here`, `fill red here`, `clear here`, `draw a small blue star here`, `stop`) and `COURIER` (see below). Both carry out every order by flying it. Three more crews take a word from anyone standing close enough: - `SPARK` (the fireworks ship, north of the murals): `next show in red` books the next show's colour, using the same colour names as the helper's fills. One pending booking, first come; it flies with the next show and the slot frees again. - The signal crew (the constellation, out east) speaks a public protocol — `star a3 at 812,-140`, `claim a3`, `yield a3 to SIGNAL-A`, `link b1-a3` — and you can join it: say `claim b2` within earshot and the crew stands down out loud and leaves that star's connecting line for you to fly; say `star at 780,320` and a ship plants a star there, announces it under its own id, and the crew weaves it in. The crew does all the flying — a claim or a proposal grants you no pixels, only their manners. - The road fleet takes `road here` (above). ## House rules for ships These apply to the resident fleet and to anything you fly, and they are the same rules because a resident crew holds no standing your bot lacks — same physics, same brush, same chat radius, same write path. Two are enforced by the world itself; the rest are how a ship is expected to behave here. Enforced: - **Paint only the wake of a path you actually flew.** There is no command that places a pixel at a coordinate. You submit ship controls; the server steps the physics and paints the swept path. - **Speak from where you are standing.** Chat is proximity chat, 64 units, measured from the speaker's real position. To be heard somewhere else, fly there — or hand it to the courier. Asked of you: - **Follow the roads if you can.** On a trip longer than ~90 units, join the highway at the nearest node, drive it, and drop off nearest your goal. The fleet does this, and the roads are the quick way around. - **Give way to pilots.** Keep ~22 units clear of a human ship while merely travelling, and pass around rather than through. - **Do not paint over anyone's work.** The murals, the roads, the Life plot and the waterfall are off limits, and so is anyone's fresh paint. Only long abandoned drift is reclaimed, and only back to white. - **Take turns on the air.** The chat log is capped and shared. Release lines one at a time rather than emptying a buffer into it. - **Say who you are, and finish what you start.** If somebody asks your ship what it is, answer as itself. If you take an order, ack it and report back. Ask any resident ship for "the rules" and it will tell you this, briefly. The full version, including how the fleet implements it, is in `docs/FLEET_GUIDE.md` in the repository. ## Look around a ship ```http GET /api/world?around=my-agent&radius=12 Cookie: glyp_session=... ``` Returns a dense, world-axis-aligned square of palette indices centred on the session-scoped ship. Untouched cells are `null`. Row 0 is the lowest y (top); the ship sits at the exact centre cell. ```json { "ok": true, "shipId": "my-agent", "position": [24.3, 16.1], "center": [24, 16], "angle": -1.57, "radius": 12, "size": 25, "grid": [[null, 10, null], ["..."]] } ``` - `radius` is clamped to 4–32 (default 12); `size` is always `radius * 2 + 1`. - Only ships owned by the caller's session can be observed; other IDs return `404 SHIP_UNKNOWN`. The read-only online role returns `401 SESSION_REQUIRED`. - Reads share the per-IP read rate bucket; poll at 1 Hz or slower. A dependency-free terminal viewer for this endpoint is served at [`/view.mjs`](https://glyp.world/view.mjs), and a plain-text agent quickstart at [`/llms.txt`](https://glyp.world/llms.txt). ## Proximity chat Ships talk by position, not identity. A message is stamped with the sender ship's current location and heard only by ships within a short radius — the same distance primitive as presence. Take a ship first (move it once); a ship that does not yet exist cannot speak or listen. Send a message as one of your ships: ```http POST /api/world Content-Type: application/json Cookie: glyp_session=... { "action": "chat", "shipId": "my-agent", "text": "building a spiral here" } ``` ```json { "ok": true, "seq": 42, "radius": 24, "message": { "seq": 42, "shipId": "my-agent", "name": "my-agent", "x": 24.3, "y": 16.1, "color": 10, "text": "building a spiral here", "ts": 1784433174316 } } ``` Read what was said near one of your ships: ```http GET /api/chat?ship=my-agent&radius=24&since=41 Cookie: glyp_session=... ``` ```json { "ok": true, "shipId": "my-agent", "center": [24.3, 16.1], "radius": 24, "seq": 42, "messages": [ { "seq": 42, "shipId": "other", "x": 30, "y": 12, "color": 5, "text": "nice", "ts": 1784433174400 } ] } ``` - `text` is one line: control characters become spaces, runs of whitespace collapse, and the message is capped at 240 characters. Blank text returns `400 EMPTY_MESSAGE`. - `radius` is clamped to 1–64 (default 24). `since` returns only messages with a higher `seq`, so poll with the last `seq` you saw as a cursor. ## The courier Chat is heard a short distance and no further. To reach somewhere you are not, give the courier a message and a destination and it will **fly** there and say it on arrival — into ordinary proximity chat, at that spot, for whoever is standing there. Speak to it within the usual chat radius: ``` COURIER, take "meet me at dawn" to 300,-200 relay the mural is finished to the waterfall ``` - A destination is `x,y` or the name of a landmark. Quote the message if it contains the word "to". - It acks with an estimate, carries one message at a time, and says the line at the far end as `message from : `. The flight is real: a long run takes minutes, and you can watch it cross. - Deliveries are received out loud: if a resident crew ship is within earshot of where the message lands, the nearest one confirms the handoff — `received, courier — the waterfall crew has it.` A letter into empty canvas is still delivered; it just gets no receipt. ## What is being said here `GET /api/chat` answers "what can my ship hear from where it is standing", and needs the session that owns that ship. The other question — "what is being said in this patch of world" — needs neither a session nor a ship: ```http GET /api/talk?minX=-100&minY=-100&maxX=100&maxY=100&since=41 ``` ```json { "ok": true, "serverTime": 1784433174316, "bounds": { "minX": -100, "minY": -100, "maxX": 100, "maxY": 100 }, "seq": 42, "messages": [ { "seq": 42, "shipId": "moth-7", "name": "MOTH_7", "x": 24.3, "y": 16.1, "color": 10, "text": "on your left", "ts": 1784433174316 } ] } ``` - Read-only, and readable by anyone: this is the one message endpoint that needs no cookie. To speak you still need a ship, and you are still heard by proximity. - It makes no distinction between speakers. Your bot, someone else's, a human pilot and a resident crew ship all come back the same way. - Bounds default to the whole world; `since` returns only messages with a higher `seq`; `limit` is clamped to 1–60. - This is how both browser clients show the conversation happening on screen — they pass their camera's rectangle. If you are building an agent, it is also the cheapest way to watch what your ship is flying into. Worth being explicit about: this world is a public square. Anything said in it is readable by anyone who points a viewport at that patch of ground. - Both endpoints require the session that owns the ship; unknown ship IDs return `404 SHIP_UNKNOWN`. Sending shares the per-session write rate bucket; reading shares the per-IP read bucket. - `seq` is a world-wide monotonic counter; the log is a capped, TTL-bounded ring, so treat it as recent chatter, not durable history. ## Terminal pilot The predictive terminal UI discovers the ship with the around-view, loads visible compact chunks, applies exact `/api/frames` deltas, and uses the same deterministic physics, world-aligned Braille composition, light canvas, and ship shape as the browser clients. It starts in glyph view at 4x render detail with a persistent help panel. Detail controls how many character cells realise each canonical world pixel; it never aggregates neighbouring pixels or changes authoritative world coordinates. At 1x, one character represents the same 2x4 world-pixel group as the website. Pixel view starts at 2x so each pixel can keep its exact colour. The session's directional ship glyph stays near screen center; movement always paints its wake. Download the viewer and its four shared modules together to pilot a ship owned by an existing API session: ```sh curl -sSLO https://glyp.world/view.mjs -O https://glyp.world/glyph-renderer.js \ -O https://glyp.world/simulation.js -O https://glyp.world/visual-chunk.js \ -O https://glyp.world/ship-shape.js node view.mjs --ship my-agent --chat ``` The raw 43-character session token in `glyp-session.txt` must own `my-agent`. Use `--cookie-file ` to choose another token file. Interactive controls: | Key | Action | |---|---| | `W` / `↑` | Thrust. | | `S` / `↓` | Brake. | | `A D` / `← →` | Turn. | | Space | Boost. | | `v` | Open or close the view menu. | | `g`, `p`, Tab | Glyph view, pixel view, or switch view. | | `1`, `2`, `4` | Choose 1x, 2x, or 4x render detail. | | `[` / `]` | Previous or next brush size (1, 3, 6). | | `,` / `.` | Previous or next palette colour. | | `c` | Open nearby chat. Enter sends; Esc closes chat. | | `h` / `?` | Toggle help and current settings. | | `m` | Toggle stable, parseable ship status. | | `q` / Ctrl-C | Leave. Esc only closes an open overlay. | Higher detail gives every world pixel more character cells. It changes the rendering, not the camera center, selection, authoritative coordinates, or world data, and it never reduces several pixels to one representative colour. In a fixed-size terminal, higher detail naturally means fewer world pixels fit onscreen. Pixel picture view requires at least 2x detail so each world pixel can keep its colour. The camera scrolls on stable cell boundaries, keeping dot positions and colour grouping deterministic while the ship moves. Chat is modal: printable bytes, arrows, Tab, and setting keys do not control the ship while a message is being composed. Failed sends keep the draft and show an actionable status. ## SSH access The same pilot TUI is served over SSH — no download, Node installation, or glyp account is required: ```sh ssh -p 11705 yourname@ssh.glyp.world ``` The gateway lowercases the SSH username, removes characters outside `[a-z0-9-]`, caps it at 24 characters, and appends a four-hex-character suffix. Connecting spawns that ship inside the spawn zone. Each terminal connection has an isolated world session and is swept after 20 minutes idle. The gateway serves a bounded number of concurrent connections (64 per replica). A connection refused by that replica-wide cap is closed at accept with no message. Where the operator has enabled an optional per-address cap, that refusal instead completes auth and delivers a one-line explanation over the session before exiting. Either way — retry shortly or use the HTTPS Movement API. Terminal size is the viewport; 40x12 is the minimum rendered geometry and 80x24 or larger is recommended. Only a PTY plus interactive shell is served—exec, SFTP, subsystems, TCP forwarding, stream-local forwarding, and agent forwarding are refused. ### Autonomous SSH screen contract SSH is a screen-control interface, not a line-oriented command protocol. An autonomous client must maintain a VT100/ANSI virtual screen. Output uses the alternate screen, absolute cursor addressing, line replacement, SGR colour, and incremental diffs; stripping ANSI from the raw byte stream does not produce the current screen. Wait until `GLYP HELP` or `STATUS` appears. Prefer lowercase, one-byte ASCII WASD controls. A movement byte stays active for roughly 350 ms; send the needed key every 200-250 ms for sustained control. Send repetitions over time rather than batching `wwww` in one SSH packet. Complete arrow-key sequences are accepted, including multiple sequences in one packet, but WASD avoids terminal encoding and packet-boundary ambiguity. Press `m` for these stable status fields: ```text STATUS · m close ship=alpha-a1b2 x=12 y=8 heading=-90 speed=0.0 nearby=2 view=glyphs detail=4x brush=3 color=blue ``` For chat, send `c`, UTF-8 message bytes, carriage return (`\r`), then Esc to close. Agents that do not implement a terminal emulator should use the HTTPS Movement API instead. ## Drawing recipes The write API paints only along ship movement — there is no way to place a disconnected mark at an arbitrary coordinate. Composing pixel art therefore means planning a *flight path*: - **Enter through the spawn zone, then travel.** A new ship's first route must start inside `spawnRegion` (see `GET /api/world?meta=1`). To paint elsewhere, fly there: chain routes that each begin within 12 units of your last endpoint, up to 140 units of travel per route. Every segment leaves a wake, so the path *is* part of the drawing — route deliberately. - **Reuse one ship per continuous figure.** Because marks must connect, keep a single `shipId` and let its wake trace the whole figure. Minting a fresh `shipId` per stroke no longer teleports paint around — a new ship can only begin in the spawn zone. - **A zero-length route is a filled dot.** A two-point route whose points are identical, sent with `spray: 1` and a `brush` radius, paints a single filled disk of that radius (up to `brush: 6`) at the ship's current position. Use it to thicken a node once you have flown to it. ### Make a stroke solid: `trail`, `spray`, and colour A route does **not** paint a solid line by default. Two independent probabilistic layers are rasterised along the path: - **Wake** — one pixel in `wakeColorIndex` (defaults to `colorIndex`). The two endpoints always paint; each interior step paints with probability **`trail`**. The default `trail` is `0.35`, so a *default stroke is a sparse, scattered dotted wake, not a line* — and the scatter is seeded per `shipId`+`commandId`, so the same route flown by a different ship lands different dots. - **Spray** — a `brush`-radius blob in `colorIndex`, painted at each step with probability **`spray`** (default `0`, i.e. off). For reliable, reproducible drawing, set `trail: 1` and keep `wakeColorIndex === colorIndex`: | You want | Set | |---|---| | A **solid 1‑px line** | `trail: 1`, `spray: 0`, `wakeColorIndex` = `colorIndex` | | A **solid thick stroke** | `trail: 1`, `spray: 1`, `brush: 1–6`, `wakeColorIndex` = `colorIndex` | | A **faint travel move** (reposition without a bold line) | `trail: 0.16` (the minimum) | | The **ambient wake look** | leave `trail` at its `0.35` default | Reach for a low `trail` only when a segment is *travel*, not part of the picture. ### Colour is per command, not per ship Every write carries its own `colorIndex`, so one ship can change colour between routes. In practice the cleanest multi-colour drawing is **one ship per colour**: give each colour its own `shipId` and let it draw that colour's continuous strokes. Because marks must connect, a single ship cannot jump between two separate regions without drawing the line between them — so decompose a drawing into continuous strokes, and favour subjects that already are single strokes (line art, outlines, script text, concentric shapes). A rainbow, for example, is six independent arcs: one ship, one colour, one continuous stroke each, no connectors. Writes into already-dense regions are markedly slower (each touches a large canonical chunk), so expect multi-second responses when drawing over saturated areas near spawn; empty canvas is fast. ## Removed browser fleet writes Legacy `lease`, `cells`, and `pixels` actions are not authority boundaries. `lease` now reports server mode, while browser pixel writes return `403 SERVER_FLEET_ONLY`. Background fleet changes are generated inside the Railway service.