diff --git a/FABRIC-3.md b/FABRIC-3.md index 9770b20..7fbe1a9 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -1144,43 +1144,146 @@ not built on top of or left in place. --- -## D. Tripod final shape — minting, one-time Zuse fuse, messaging-only (vision, not yet scoped) +## D. Tripod final shape — minting, one-time Zuse fuse, messaging-only (vision, substantially expanded 2026-08-27) Stated directly by Captain Bob, 2026-08-25: "we're going to have to iterate because I know -what the final shape of the tripod will be." Recorded here as a forward-looking vision, not -yet broken into implementable items — captured so near-term Stadium/VM work (§B above) is -made against the right end-state rather than in ignorance of it. Full detail also saved as -memory `project_tripod_final_shape_vision.md`. +what the final shape of the tripod will be." Originally captured as a forward-looking vision, +not yet broken into implementable items. **2026-08-27: expanded into a much fuller picture** +after Phase 8/Milestone 6 closed and unblocked this design pass — captured here in full before +any of it gets scoped into implementable items, per direct request ("capture EVERYTHING first +then we'll build a plan"). Full detail also in memory `project_tripod_final_shape_vision.md`. + +### D.1 — Original vision (2026-08-25), still accurate - **Thumbdrive presentation → legality check → mint.** A newly presented thumbdrive is - checked for legality (against the CA-root-derived identity/certificate scheme already - decided earlier this session, `FABRIC-2.md`). If not legal, it is "minted" — formatted for - system use — which (1) spins a new user VM and (2) attaches the console VM to it. + checked for legality (against the CA-root-derived identity/certificate scheme). If not + legal, it is "minted" — formatted for system use — which (1) spins a new user VM and (2) + attaches the console VM to it. - **One-time Zuse mint + fuse-blow on first install.** A brand-new system instance ("Install"/"Try It") mints exactly one Zuse superuser, then irreversibly "blows a fuse": direct quote, "we mint one and only one Zuse user and blow a fuse. The only way around is a new system." Post-fuse, no further Zuse can ever be minted on that instance — but the system is NOT bricked: the existing Zuse superuser keeps working, and ordinary users can - still "thumb in" via regular thumbdrives. + still "thumb in" via regular thumbdrives. **This half is now actually built** — Phase 8's + entropy→signing→block-fence persistence work (2026-08-26, `project_phase8_milestone6_complete.md`) + implements exactly this, minus the physical thumbdrive itself (see D.4, WRITE(10) gap). - **Messaging-only once Tripod is fully live.** All inter-VM interaction becomes Hermes messaging, not direct calls/shared state — a stated end-state, not the current - implementation. -- **Polymorphic block-boundary behavior for user VMs.** Stated in one sentence, not yet - elaborated: a user VM needs to behave polymorphically when crossing block boundaries. - Needs a dedicated follow-up conversation before this is actionable. -- **`ClaudeEXPORT/`** (repo root, new as of 2026-08-25) — a prior Claude data export the user - pointed at for "concepts and thoughts as guidelines" on this vision, explicitly flagged as - possibly containing superseded/conflicting ideas, not authoritative. `conversations.json` is - ~66MB; mine selectively (grep or a subagent) rather than reading wholesale. See memory - `project_claude_export_archive.md`. + implementation. **Reaffirmed and sharpened 2026-08-27: hardwired/direct-call + implementations are acceptable *during development only* — no piece of this design is + considered actually finished until its hardwired calls are replaced with real Hermes + messages.** This is a standing completion criterion for everything in this section, not a + separate future milestone. +- **Polymorphic block-boundary behavior for user VMs.** Still just one sentence, still not + elaborated — genuinely unresolved since 2026-08-25, needs its own follow-up conversation. +- **`ClaudeEXPORT/`** — a prior Claude data export, "concepts and thoughts as guidelines," + explicitly flagged as possibly containing superseded/conflicting ideas, not authoritative. + See memory `project_claude_export_archive.md`. + +### D.2 — The session model (2026-08-27): a session IS a VM + +Direct correction to how this document and the earlier `EXPIRE` framing (§B) had been +thinking about "sessions": **a session is any VM client running in the Stadium fabric — Zuse +is no different from any other VM.** The Stadium/FABRIC metaphor restated by Captain Bob: +the fabric floats inside the Stadium; VMs actually doing work are "players on the field" +(system perturbances); user interaction is "fans in the stands" providing patron-driven noise. +Zuse is a player like any other, not a special boolean flag on Hera. + +**This directly invalidates the `EXPIRE`-as-TTL-on-`zuse_session`-boolean plan this session +had started scoping (§B's `EXPIRE` decision, and the implementation research begun +2026-08-27 before this correction landed).** Today's `zuse_session` field on the VM struct is +not what a "session" actually is in this model — a session ending is a **VM detaching**, far +closer to the existing, real, working `COOL`/`capsule_vm_kill()` path than to a new +Stadium-behaviour-tag TTL sweep. **`EXPIRE` as originally scoped is superseded, not merely +deferred** — when Stadium/ACL session-lifetime work is picked up again, it should be framed +as "what happens when a user-VM's owning thumbdrive detaches," reusing `COOL`, not as a +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. + +### D.3 — The attach/mint flow, end to end + +1. **Idle loop watches for thumbdrive connects** (`sk_repl_idle()`, already the right hook — + confirmed 2026-08-27 during the (superseded) `EXPIRE` research: ~1s cadence, already used + for `xhci_poll_events()`/MSC attach). +2. **Cert-only authentication — no password, no username.** A presented thumbdrive's identity + is *entirely* the cert on it. Verification means checking the cert's fields directly (chain + of trust, most likely signed by *Zuse's own key* — the same `x509_ed25519.c`/ + `ed25519_verify()` primitives Milestone 6 already built and proved work end to end, just + verifying against Zuse's pubkey instead of the snakeoil intermediate's). **The system has + no requirement to maintain any single identity itself** — no user directory, no central + registry of who exists. Each thumbdrive is a fully self-contained, portable identity + record. +3. **A dedicated user VM is born** from the identity's own data — "the users/agents/services + metadata can reside in their capsule and [get] encoded directly into their dictionary when + they attach and their init.4th executes." This is a *runtime*-constructed capsule from + drive content, not a build-time-embedded one like `pki:snakeoil-intermediate.der` — a + materially different mechanism from anything `mkcapsule` does today (gap, see D.4). +4. **The console VM attaches to the new user VM** — this is exactly Milestone 5's still-open + "Console/VM key-match binding" item, now with its open question *resolved*: "the bumps on + a thumbdrive have to fit the holes on the VM... (ACL territory)" — **reuse the existing + ACL primitive (`acl_mode`/`acl_allow`/`acl_pinned`) for the key-match check, don't build a + separate mechanism.** Exact comparison semantics still undesigned (see D.4). +5. **The user plays entirely inside their own VM** — all their FORTH activity happens in + their own isolated VM context, never Hera's or anyone else's. +6. **Ongoing minting**: while Zuse is attached/active, a second blank thumb presented can be + minted with a new named identity (worked example given: `S" CaptBob" MINT`-shaped flow) + and ejected — this is the still-open `MINT` word from Phase 8's own punch list, now with a + concrete attach-flow context to design it against. +7. **Detach**: working state is copied back to the user's own thumb and flushed before eject. + **Explicitly deferred — stated directly as "going to be a maintenance operation later," + not needed now.** + +### D.4 — Gaps identified 2026-08-27, sorted by whether they're answered + +**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. +- 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). + +**Real, unanswered gaps — deferred on purpose (per "answer what we can, defer what we +can't"):** +- **How does thumbdrive content actually become a capsule at runtime?** `mkcapsule` only + ever builds capsules at build time, baked into `capsule_generated.c` — nothing today + constructs a capsule from data read off a live-attached device. This is new mechanism, not + a variation on anything that exists. +- **Exact ACL "bumps and holes" comparison semantics.** Which specific ACL fields, compared + how, constitute a console-to-VM match? Direction is settled (reuse ACL), the actual + comparison logic is not designed. +- **Message-bus migration scope.** Which specific interactions (attach detection, cert + verify, console bind) move to Hermes messages, and what do those message shapes look like? + Entirely unscoped, explicitly deferred until after a hardwired version exists to migrate + *from*. +- **Polymorphic block-boundary behavior for user VMs** — still just the one original sentence + from 2026-08-25, never elaborated. +- **SSD identity-store scope** — does the system-resident store (the block-fence built in + Phase 8) ever hold anything about *regular* users, or is it purely Zuse/system bookkeeping + with regular users staying purely thumbdrive-resident? Best read of what was said: the + 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. +- **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 + media. None of D.3's flow can run on real hardware until this lands; QEMU testing would need + to proxy through a writable virtio-blk stand-in the same way Phase 8's cert persistence did + for Zuse's own identity. + +**Small, unrelated, real bug found along the way:** the prompt shows `zuse)ok>` (a stray +trailing paren, "never corrected typo") — should be `(Zuse)ok>`, both parens around the +identity name, generalizing to any attached identity (e.g. `(CaptBob)ok>`). Independent of +everything else in this section; safe to fix any time. **Why this affects §B:** VM-`COOL` (and any inter-VM Stadium wiring) sits close to this -still-iterating design. Building it now risks conflicting with or being thrown away by the -Zuse/messaging shape once that gets its own pass — hence §B's punch list defers VM-`COOL` -explicitly rather than resolving it in this pass. Block-patron `MIGRATE` work does not -obviously depend on this vision and is not deferred for this reason. +design — see D.2's `EXPIRE` supersession above, the concrete example of exactly this risk +materializing. -**Next step:** no implementation here yet. When this gets its own design pass, start by -clarifying "polymorphic block-boundary behavior" and the exact legality-check mechanism -(presumably the CA-root certificate scheme), then scope minting as its own capsule-birth-style -protocol (mirroring the existing capsule birth writeup's rigor) before writing any code. +**Next step:** no implementation yet — this section is capture only, per direct request. Next +session should turn D.3/D.4 into an actual scoped, ordered plan (the user's own framing: +"identify gaps, answer what we can, defer what we can't... push the pile out in front of us").