From ec78b28f113951547342eabd9ff467c5f3c5f758 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Sat, 22 Aug 2026 07:05:57 -0400 Subject: [PATCH] FABRIC-2.md Section W: Artemis concept board -- consolidated vision in one place, pulling together Sections U and V Single-read consolidation of the whole Artemis thumbdrive/home-blocks/ PKI vision: one-paragraph statement of intent, a component table cross-referencing each piece to its detail (Section U) and verified status (Section V), and explicit sequencing with the actual near-term milestone first -- bare-metal boot from a physical USB stick in demo/ "try it" mode, confirmed NOT gated on the USB hardware driver gap since booting from USB is a UEFI firmware responsibility, not a kernel one. The existing starkernel.iso/raw-disk-image build artifacts (built on every QEMU launch already) are, mechanically, what gets dd'd onto a physical drive for this. Two 64GB SanDisk drives confirmed on hand and available now. Everything else in the concept board explicitly waits on the USB hardware driver as the singular hard prerequisite. Still direction only -- nothing implemented, no hardware testing done. Co-Authored-By: Claude Sonnet 5 --- FABRIC-2.md | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/FABRIC-2.md b/FABRIC-2.md index c8253b7..7344bb6 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -2902,3 +2902,67 @@ flag, QEMU monitor socket exposure, install path. at all, even in QEMU: the USB stack itself (area B).** Every other gap in areas A, C, D, and H either directly requires it or becomes untestable without it. This is the honest first-cut recommendation if a concrete next milestone gets picked from this analysis. + +--- + +## W. Artemis concept board — consolidated vision, one place, 2026-08-22 + +Sections U and V are the detailed working log (every requirement in the order it came up, +then the gap check against the code). This section is the single consolidated picture pulled +from both, requested explicitly so the whole shape exists in one place rather than only as a +trail of addenda. **Still direction, not a spec — nothing here is implemented.** + +**The vision, in one paragraph.** Two physical identities, each minted onto its own USB thumb +drive via Ed25519 PKI (Captain Bob as operator, `zuse` as superuser) — the same drives double +as both credential and portable storage. Insert a drive, and the system authenticates that +identity, spins up (or re-attaches) that identity's own VM, and binds a generic, shared +console to that VM alone via a key/lock match. That identity's data lives across a +transparent, bidirectional migration between the main SSD and the drive itself — the drive +carries its own map of what's theirs, so the SSD needs no central per-user directory, and +block ownership is derived from identity rather than from insertion order, so it's identical +every time regardless of which drive got plugged in first that session. Everything the system +loads — the kernel's own trust root down through every capsule — is signed and verified +against a certificate embedded in the kernel image, chained to a CA that never itself gets +embedded or loaded. A foreign or unrecognized drive gets refused with a warning, not silently +overwritten; the zuse credential, once minted, can never be re-minted. + +**The components, each pointing at its detailed treatment:** + +| Component | Detail | Status (Section V) | +|---|---|---| +| Block address space + device chain | U items 1-2 | ✅ exists | +| Identity-derived block ranges | U item 3 | ❌ not started | +| Drive-carried block map | U item 4 | ❌ not started | +| Bidirectional migration state machine | U item 5 | ❌ not started (trigger hook ready) | +| Foreign-drive protection | U item 7 | ❌ not started (magic-number precedent exists) | +| Zuse one-way burn | U item 8 | ❌ credential unbuilt (ratchet mechanism exists) | +| Console/VM key-match binding | U item 9 | ❌ not started (VM spin-up call exists) | +| Kernel/capsule PKI signing chain | U items 10-14 | ❌ not started (manifest anchor + blob embedding exist) | +| Contributor capsule directory/trust tiers | U items 15-18 | ❌ not started, explicitly sequenced last | +| USB hardware (xHCI + MSC r/w driver) | Gap analysis area B | ❌ zero code, the hard prerequisite | +| Capsule distribution server (Nexus-style) | later conversation | ❌ concept only | +| Live-boot ISO ("try it") | area H | ✅ exists and works today | +| Install path ("install it") | area H | ❌ not started, explicitly deferred — "not that risky yet" | +| QEMU monitor socket (dev iteration) | area B | ❌ one-line gap, not blocking | + +**Sequencing, as currently stated across the whole conversation, nearest-term first:** + +1. **Bare-metal boot from a physical USB stick, demo/"try it" mode only — the actual next + milestone**, confirmed this session as *not* gated on the USB-hardware-driver gap above. + Booting *from* USB is a UEFI firmware responsibility, not a kernel one — the same + `starkernel.iso` (amd64/aarch64, El Torito) or raw disk image (riscv64) already rebuilt on + every QEMU launch this session is, mechanically, the artifact to `dd` onto a physical drive. + Two 64GB SanDisk drives are on hand and available right now for this; one currently carries + a Kubuntu 26.04-era live ISO, re-flashable without loss (re-downloadable). Real-hardware + UEFI firmware varies from QEMU's OVMF, so the first real boot is a genuine test, not a + formality — noted, not treated as a blocker. +2. Everything in this section's component table below the live-boot-ISO row — the actual + home-blocks/thumbdrive-as-persistent-identity-storage subsystem — waits on the USB + hardware driver (area B), which is the honest, singular hard prerequisite once milestone 1 + is done. +3. Contributor capsules/trust tiers, explicitly sequenced after the ACL/PKI work closes. +4. Networking (capsule distribution server, WiFi), explicitly sequenced after that. + +Not started: no code, no capsule work, no hardware testing yet. This section exists so a +future session (or Captain Bob re-reading cold) gets the whole shape in one read, rather than +needing to reconstruct it by reading U, V, and this section's own cross-references in sequence.