From 1d0df69127a49f0f369ebe10f9a9fc023a3d05f4 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Thu, 27 Aug 2026 09:52:20 -0400 Subject: [PATCH] Link Tripod vision to Stadium foundation theory + capture the pentagon MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit No code changes -- continued design capture, per direct request to link today's vision into the existing FABRIC.md/FABRIC-2.md material ("the existing pile of dirt") before planning. Mined FABRIC.md's original Stadium theory (§17.1, §20, §24) and found the EXPIRE-as-TTL correction wasn't just cleaner once "session=VM" landed -- it was required from the start: the foundational patron/departure table already says VMs depart via heat decay (COOL), never TTL (TTL only ever governed messages/ACLs). §20's outer/inner Stadium nesting already anticipated "attach = admit a VM" as a case, so no new Stadium theory is needed, only a new admission trigger. §24's identity-stability rules don't block session-state round- tripping across separate attaches either way. Mined FABRIC-2.md and found real grounding for two more decisions: the acl_pinned one-way-ratchet was already identified as the right shape for both Zuse's "burn" and console-session ownership, just never built past word-execution gating -- and the real Hermes message shape (MSG-CELLS, 9 fields, out-of-line payload, MSG-ALLOC/CH-ALLOC/ MSG-DELIVER) gives message-bus migration a concrete target instead of an abstract goal. Confirmed empirically that today's xHCI hotplug attach chain is 100% hardwired, zero messaging anywhere in it -- the real baseline to migrate from. Captured the pentagon topology: "just to get a user, 5 VMs are needed" -- Hera, Hermes, Artemis, the user's own VM, and the Console, fully interconnected (K5, a pentagon with every diagonal drawn). Flagged the Console as a full peer node, not the passive relay D.3's flow description implied -- reconciling that phrasing against the five-node picture is new open work. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd --- FABRIC-3.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/FABRIC-3.md b/FABRIC-3.md index 7fbe1a9..09df0a0 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -1202,6 +1202,51 @@ timeout on a flag. When Hera has no VM attached beyond fleet-servicing strata, she idles, watching services and maintaining a serviced fleet foundation — her normal steady state, not a special case. +**Validated against the original Stadium foundation, not just today's intuition (mined +2026-08-27 from `FABRIC.md` §17.1/§20, the oldest, most foundational layer of this whole +design — see D.2b below for the full mining pass).** `FABRIC.md` §17.1's own patron/departure +table already says VMs depart via heat decay (`COOL`) and only messages/ACLs ever used TTL — +meaning the `EXPIRE`-as-TTL-on-a-flag plan this session had started scoping didn't just become +inconvenient once "session = VM" landed, **it contradicted the original design from the +start**: a VM was never one of the two patron kinds TTL governs. §20's outer/inner Stadium +nesting (VMs as outer-Stadium patrons; words/blocks/ACLs/messages as inner-per-VM patrons) +already anticipated exactly "attach = admit a VM patron" as the outer-Stadium case — no new +Stadium theory is needed for this, only a new *admission trigger* (thumbdrive attach) feeding +the existing admit/evict machinery. + +### D.2b — The pentagon: five VMs, minimum, to service one attached user (2026-08-27) + +Stated directly: **"Just to get a user, 5 VMs are needed — if we draw every connection to +every node they can make a pentagon."** The five: **Hera, Hermes, Artemis, the user's own VM, +and the Console.** Drawing every pairwise connection among five nodes (a complete graph, K5) +draws a pentagon with all its diagonals — visually a pentagram. Noted in passing, and worth +keeping since this project's naming is already steeped in Greek mythology (Hera, Hermes, +Artemis, Ananke/Lithos, Zuse for Zeus): a pentagram at the foundation of a "pagan" system fits +the theme, not an accident to explain away. + +**The Console is a full peer node, not a passive terminal that merely "attaches to" a user +VM** — D.3 step 4 undersells this; the Console is architecturally one of the five, with (at +minimum) its own binding relationship to the user's VM and, per the messaging end-state, +eventually its own message traffic to Hera/Hermes/Artemis too, not just a one-way relay. +Reconciling D.3's "console attaches to the new user VM" phrasing against this five-node, +fully-connected picture is real remaining work, not done here — captured as a gap in D.4. + +Why each of the five is load-bearing, best understanding as of this capture (not all edges +independently confirmed — see D.4's gaps): +- **Hera** — governs the fleet, births/kills the user VM (existing `capsule_birth_baby()`/ + `capsule_vm_kill()` path), holds the outer-Stadium quota the new VM draws from. +- **Hermes** — the messaging fabric itself; per the standing "nothing is done until it's + messaging" criterion, every other edge in this pentagon is ultimately meant to route through + Hermes, making Hermes both a node in the graph and (eventually) the medium connecting every + other edge — worth being explicit that this is a two-level relationship (Hermes as a peer VM + *and* as the substrate other peers communicate over), not a design tension to smooth over + by treating it as an ordinary fifth node. +- **Artemis** — persistent block storage; the identity/system-metadata store (Phase 8's + block-fence) and, per D.3, wherever a user's own working data actually lives during a + session, live here. +- **The user's own VM** — where the user plays (D.3 step 5). +- **Console** — the human-facing binding point (D.3 step 4, Milestone 5). + ### D.3 — The attach/mint flow, end to end 1. **Idle loop watches for thumbdrive connects** (`sk_repl_idle()`, already the right hook — @@ -1239,12 +1284,32 @@ maintaining a serviced fleet foundation — her normal steady state, not a speci **Answered (resolved during capture, not deferred):** - Milestone 5's "reuse `ACL-PIN` vs. build a new key-match primitive" question — reuse ACL. -- `EXPIRE`'s framing — superseded by "session end = VM detach," see D.2. + **Now grounded, not just intuited** (mined 2026-08-27 from `FABRIC-2.md` §C/§D, + lines ~2884-2918): `acl_pinned`'s one-way-ratchet (`include/vm.h:346`, C-only mutation, no + FORTH clear path) was *already* identified as the right-shaped precedent for exactly two + things — Zuse's own one-way "burn" and console-session ownership — but in both cases only + the *pattern* was precedented, never actually built past word-execution gating. The + "still genuinely open" framing in `FABRIC-2.md` is accurate as of that writing; today's + decision closes it, the comparison *semantics* remain the real gap (below). +- `EXPIRE`'s framing — superseded by "session end = VM detach," see D.2. **Now shown to be + required, not just cleaner**, by `FABRIC.md` §17.1's own patron/departure table (see D.2's + addendum above) — TTL was never a valid mechanism for a VM patron in the first place. - Regular-user cert chain-of-trust mechanism — signed by Zuse's own key, verified with already-built, already-proven Ed25519/X.509 primitives (Milestone 6). No new crypto work needed, only a new verification *call site* using existing functions. - Whether the system needs a central user directory — no, by design; each thumbdrive is self-contained (reinforces D.3 point 2, was implicit, now explicit). +- **The concrete target shape for message-bus migration** (mined 2026-08-27 from + `FABRIC-2.md`, cross-checked against live `capsules/hermes/init.4th`): a message is + `MSG-CELLS` = 9 cells (`TYPE, FROM, TO, PADDR, PLEN, STADIUM-CELL, SEQ, CH, ORIG-TYPE`), 72 + bytes, payload **out-of-line** (a pointer+length to caller-owned bytes — there was never a + fixed inline payload field, an earlier open question in `FABRIC-2.md` §23.4 that its own + design already closed as moot). Live API: `MSG-ALLOC ( heat -- addr|0 )`, + `CH-ALLOC ( heat -- addr|0 )`, `MSG-DELIVER ( m -- )`, `MSG-DELIVER-ALL ( -- )`. A future + "thumbdrive attach event" or "cert verify request" message type follows this exact shape — + allocate, fill `TYPE`/`FROM`/`TO`/`CH`, point `PADDR`/`PLEN` at an out-of-line event struct, + send. Not built, but no longer an abstract "use messaging someday" — there's a real API to + target. **Real, unanswered gaps — deferred on purpose (per "answer what we can, defer what we can't"):** @@ -1267,7 +1332,25 @@ can't"):** latter, but not stated explicitly enough to treat as settled. - **Does a user's VM/session state round-trip across multiple attaches** (unplug, come back later, resume exactly where you left off), given detach explicitly copies state back to the - drive? Implied yes by the detach description, not confirmed directly. + drive? Implied yes by the detach description, not confirmed directly. **Checked against + `FABRIC.md` §24's mutation/identity-stability rules (mined 2026-08-27) — no conflict either + way**: identity is only pinned stable *within one residency*, so a thumbdrive re-attaching + later and being admitted as a fresh VM patron (possibly reusing an identity value derived + from its cert/pubkey) is simply a new residency each time. Nothing in the foundational + theory blocks or answers round-tripping; it stays a pure implementation decision. +- **Reconcile D.2b's five-node, fully-connected pentagon against D.3 step 4's "console + attaches to the user VM" phrasing.** The Console is a full peer node (Hera/Hermes/Artemis/ + User-VM/Console, K5), not just a passive relay that binds to one other node — D.3's + wording undersells this. Which of the ten pentagon edges are real *today* versus aspirational + once messaging lands is not worked out; only Hera↔UserVM (birth/kill) and + UserVM↔Artemis-via-Hera's-quota (existing Stadium quota mechanics) are clearly already + real in some form. +- **Confirmed baseline before any message-bus migration can start** (mined 2026-08-27, + `FABRIC-2.md` cross-checked against live `src/starkernel/repl.c` and the xHCI/USB driver): + today's hotplug→MSC-attach→`homeblocks_sig_check()`→`blk_subsys_attach_device()` chain is + **100% hardwired, direct C calls, zero messaging at any point** — confirmed empirically, not + assumed. This is the exact, real starting point "hardwire now, message later" describes; + there is no partial messaging implementation anywhere in this path to build on yet. - **The single biggest hard blocker underneath all of it: SCSI `WRITE(10)` still doesn't exist** (`blkio_usb.c` is read-only — Milestone 2's biggest open item, unchanged). Minting a blank thumb, and flushing state back on detach, both need real writes to physical USB