@ai-ecoverse/slicc-bios 1.23.1 → 1.24.0

package/README.md

@@ -318,6 +318,10 @@ seven can also join a tailnet, with a patched build of Tailscale's wasm client (
 - **Exits:** `os/exits.js` routes traffic over any number of exits: Tailscale, and linked devices.
 - **Linked devices:** `os/link.js` links a `slicc` CLI to the page over WebRTC, as one exit per link. It speaks the [slicc link protocol](https://github.com/ai-ecoverse/slicc-cli): slicc-node's tunnel frames over data channels, with one channel per stream and a 256 KiB credit window per stream and direction.
   - **Setup:** a CLI that holds CDP to this browser calls `globalThis.sliccLinkReceive` with a `hello` and its nonce, and the page answers through the CLI's `sliccLinkSend` binding: the offer, then its ICE candidates. The CLI checks that the call came from seven's main frame. CDP carries only the setup; the data goes over WebRTC. Every `hello` names its CLI process (`node`): a new `hello` from the same process replaces its link (after a reload, say), and one from another process (`slicc prompt` next to `slicc`) adds a second link.
+  - **Pairing without CDP (`slicc open`, `slicc pair`):** `os/pair.js` is seven's side of the link spec's §1.3, for a seven in an everyday browser that no CLI controls. It needs slicc ≥ 1.39.0; the tests run the pinned `@ai-ecoverse/slicc` devDependency. `slicc open` opens `<page>#slicc-pair=<port>.<token>.<node-fp>`, and `slicc pair` prints it for the **Link this computer** field under Linked devices (`pairComputer(url)`, spectrum's pairing block, spectrum ≥ 1.88.1). Seven strips the fragment at once, opens the Network panel, and asks *Link SLICC on this computer?* with the node's short fingerprint (`ab12…ef`), which slicc prints too. Only **Link** (`confirmPairing()`) sends a loopback request: one `POST http://127.0.0.1:<port>/slicc/v1/pair` with the token and a non-trickled offer (ICE gathering waits 10 s at most, then the offer goes with what it has), from a page certificate (ECDSA P-256) kept per origin in IndexedDB (`slicc-follow`, key `loopback`). Seven uses the answer only if its fingerprint is the URL's, then pins `{ port, name }` by that fingerprint in `localStorage` (`slicc-os.paired`). It never pairs over ports 9222–9229 or below 1024. Every loopback `POST` gets 15 s (2 minutes while Chrome's Local Network Access prompt is open, which shows as `links.permission`), and a missed deadline reads as nothing answering. A tab that isn't running SLICC keeps the link until it follows the tab that is, then hands the attempt over; under a version skew between the tabs it says so instead and never pairs on its own. A tab that takes over reads the pins again. Refusals read as a sentence in the block: a wrong, used or expired link (`403`), nothing answering (or an origin slicc refuses), a browser that blocks local network access, and an impostor's fingerprint.
+    - **Browsers:** Chrome, Edge and Firefox reach `http://127.0.0.1` from an https page. WebKit (Safari, and every browser on iOS) blocks it as mixed content, so there an attempt fails at once with "Safari doesn’t let an https page reach slicc on this computer…", which points to the join command (the tray path) or another browser.
+    - **The device:** keyed by the node's fingerprint, local (the automatic exit, folders, kernel services), but with no `agent` cap, so no remote control: `slicc prompt` never goes over a pairing. Its row stays while slicc isn't running. After a reload, a lost link or a restart of slicc, the tab running SLICC posts `{ offer }` to `/slicc/v1/signal` on the remembered port, then 17117–17126, with backoff from 1 s to 30 s (and at once on `online` or when the tab shows), and takes only an answer with the pinned fingerprint. A `403` on the pinned port means slicc forgot this seven (`slicc unpair`), and the offline row says so until it's paired again. **Unlink** opens `unlink` on the live link (cap `unlink-loopback`), then forgets the pin, even when slicc isn't running or the `unlink` fails: slicc's own pin is harmless then (seven never signals again) until `slicc unpair` removes it.
+    - **Tests:** `test/integration/pair.test.mjs` runs the real `slicc pair` and `slicc open` with no `--cdp`: kernel `curl` and a `--mount` folder over the link, the debugging ports refused through it, a reload and a restart of slicc that link again without a new URL, Unlink after which `slicc unpair` lists nothing, a wrong and a used token, a stopped slicc, ports 9222 and 80 refused before any request, the address bar, a second tab (which keeps the device once the first closes), a second tab under a version skew, and a slicc that forgot this seven. `test/integration/vendors/pair.test.mjs` pairs an https page (routed by Playwright) with the real `slicc pair` in Firefox, and checks WebKit's refusal; CI runs it in its own job, `ci / vendors`, on a GitHub-hosted runner with Playwright's Firefox and WebKit.
   - **Before HELLO:** each stream channel is its own SCTP stream, so a node's first OPEN can reach the page ahead of its HELLO on the control channel, the order a `slicc prompt`, `abort` or `watch` sometimes arrives in. The page holds up to 64 such frames, 256 KiB in all (one stream's credit window), and serves them in order once the HELLO arrives, as the CLI does for the page's; frames held on a channel that closed meanwhile are dropped. A frame on the control channel before HELLO, a 65th held frame or byte past 256 KiB, a held frame that turns out malformed, and no HELLO within 10 s still close the link: before its HELLO a peer is anonymous.
   - **Half-open links:** a link that hasn't said HELLO within 30 s of its offer (a follower that gave up on a bootstrap, say) is closed, and its peer connection with it. A device's row follows its link that said HELLO, never a newer half-open one; with only a half-open link left, a known device shows as away. Until a link says HELLO its row shows only that it's connecting, under its bootstrap id: no *Asks to follow*, no Allow and no switches, because its device isn't known yet. So Allow, which keeps the grant with the device's certificate, always finds the device it was clicked for. Unlinking a device drops every link it has and tells the ones that said HELLO.
   - **Names:** each link gets an address from `198.18.57.0/24` (the first is `.11`) and the name `<host>.slicc.internal`, from the CLI's hostname, made DNS-safe and unique (`lars-mbp-2`). A link keeps its name when it reconnects, also after a reload and in any order, while the name is free: the page remembers each CLI process's name (by device certificate and process id) in `localStorage` (`slicc-os.link-labels`). A CLI that restarts is a new process, so it may come back as `lars-mbp-2` while its old link is still closing; once that link is gone, the new one takes the name back (and its SSH host key is written under it). Port 22 there is the CLI's built-in SSH server, and any other port is the CLI machine's loopback, under the CLI's policy.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-bios",
-  "version": "1.23.1",
+  "version": "1.24.0",
   "description": "Slim loader that boots SLICC into OPFS and serves the UI from there",
   "type": "module",
   "license": "Apache-2.0",
@@ -47,7 +47,7 @@
     "@ai-ecoverse/slicc-node": "2.5.1",
     "@ai-ecoverse/slicc-shared-web": "1.24.2",
     "@ai-ecoverse/slicc-spectrum": "1.89.1",
-    "@ai-ecoverse/slicc-vault": "1.12.1",
+    "@ai-ecoverse/slicc-vault": "1.12.2",
     "@biomejs/biome": "2.5.15",
     "es-module-lexer": "3.0.3",
     "fake-indexeddb": "6.2.5",