From 89d814f9f3cdd0a95162abeeda105463bca72e9d Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Thu, 3 Sep 2026 05:43:22 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC-3.md=20=C2=A7H:=20close=20all=20three=20?= =?UTF-8?q?remaining=20design=20gaps?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Gap #1: closed set of four cards (VM/word/block/message), no new cards for now. Gap #2: creator-ceiling enforcement is a birth-time snapshot copy, not a live ACL-RECHECK-time check -- reversed mid-conversation once the live-check approach's cross-VM dictionary-lookup problem surfaced; final rationale is child program stability (a program developed against one ACL set must not have it silently changed by later parent changes). Gap #3: Zuse's eligibility list persists in the existing growable metadata-fence mechanism as a simple owner_pubkey[32] list, no extra per-entry metadata. Every design-level question in this refactor is now closed. What remains is pure implementation (5 items) and two intentional deferrals. Co-Authored-By: Claude Opus 5 --- FABRIC-3.md | 77 ++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 58 insertions(+), 19 deletions(-) diff --git a/FABRIC-3.md b/FABRIC-3.md index 7520919..1af54d0 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -3630,11 +3630,17 @@ pinholes drop all the way down through and give the permission for whatever we'r work[ing on]... a set of graduated sieves." Confirmed accurate by the user. **Each card is one permission dimension**, not a redundant extra layer of the same check — -named dimensions so far: VM, word, block, message. A compound action (e.g. "execute word X, -which touches block Z and sends message M") passes through the word card, the block card, and -the message card at once — one card per relevant axis. **Confirmed: an action only consults -the cards for the dimensions it actually touches** — a pure VM-level operation only checks the -VM card, not the full stack every time. +named dimensions: VM, word, block, message. A compound action (e.g. "execute word X, which +touches block Z and sends message M") passes through the word card, the block card, and the +message card at once — one card per relevant axis. **Confirmed: an action only consults the +cards for the dimensions it actually touches** — a pure VM-level operation only checks the VM +card, not the full stack every time. + +**Closed set, resolved 2026-09-03**: VM, word, block, and message are the complete set — "closed +set, no new cards, naturally, subject to change." Not permanently frozen, but not open-ended +by default either — a fifth card (e.g. a "console" dimension, given the D.2b pentagon names +Console as a full peer node) would be a deliberate future decision, not something implicitly +already on the table. **Word-ACL reconciliation resolved 2026-09-02.** Checked `capsules/ACL.4th` directly: both existing modes (`STRICT` — "always allow, TTL stays 0 (recheck always)"; `TTL` — "compute TTL @@ -3647,10 +3653,24 @@ reused as-is.** The stack-of-cards framing is new vocabulary for what already ex new mechanism. **The one genuinely new piece, not present in today's system at all**: creator-ceiling -enforcement. Nothing today caps a newly-birthed VM's word-ACL state against its parent's — -this needs to happen somewhere in capsule birth (copying/capping the child dictionary's -`acl_allow`/`acl_mode`/`acl_pinned` against the parent's own values at birth time). Where -exactly this lands in the birth flow is not yet designed. +enforcement. Nothing today caps a newly-birthed VM's word-ACL state against its parent's. + +**Mechanism decided 2026-09-03, after a mid-conversation reversal.** First proposed: hook the +ceiling check into the existing `ACL-RECHECK` cold path (checked later, no birth-time copy) — +initially agreed, but this runs into a real problem: each VM has an entirely separate +`DictEntry` dictionary (H.10), so `ACL-RECHECK` running inside a child would need a live +cross-VM lookup back to the parent's own dictionary state, never designed. On seeing this, the +user reconsidered: **"perhaps a fast copy might be cheaper and just as effective."** + +**Final: birth-time snapshot, no live sync, ever.** The child's `acl_allow`/`acl_mode`/ +`acl_pinned`/`acl_ttl` are copied from the parent once, at birth — no ongoing reference back +to the parent afterward, which solves the cross-VM lookup problem outright. The child's own +ACL state can still grow/shrink dynamically after birth (the word card's "additive/subtractive" +framing still holds); it just starts from the snapshot rather than staying synced to the +parent's *current* state. **Explicit rationale, user's own words**: "if something was +developed with a particular set of ACLs, it should remain at that — otherwise parent changes +break the child's program." Program stability for the child, not administrative convenience, +is why live-sync was rejected. ### H.4 — VM card @@ -3699,9 +3719,16 @@ retarget, quota grant, etc.) — those are finer-grained checks built elsewhere. path only. - **Eligibility gate on top of the trigger, user-proposed**: "maybe zuse keeps a list of users that can be granted zuse caps?" — confirmed as a gating layer, not a replacement for the - trigger. Zuse checks this list (presumably keyed by `owner_pubkey`, matching H.4's - single-owner VM-card shape) before honoring any elevation request. Exact list - representation/storage not yet designed. + trigger. Zuse checks this list (keyed by `owner_pubkey`, matching H.4's single-owner + VM-card shape) before honoring any elevation request. +- **Storage decided 2026-09-03**: persists across reboots, living in Zuse's already-built + growable metadata fence at the top of Artemis's block device (the same mechanism that + already persists Zuse's own `zuse_cert_devblock_t` identity — see Phase 8/Milestone 6). + Shape: a simple growable list of `owner_pubkey[32]` entries, no extra per-entry metadata — + "simple list, no extra metadata, unless we find a reason this won't work" (provisional + lean-by-default, not a permanent ban on adding fields later). Not yet designed: the actual + record format added to the metadata fence; how entries get added (presumably a Zuse-only + FORTH word, unbuilt); exact relationship to the still-unbuilt `MINT`-a-second-identity flow. ### H.6 — Block card @@ -3861,11 +3888,15 @@ ones. This supersedes §H.9 as the current accurate picture; §H.9 itself is lef as historical record (each item already carries its own closure annotation inline). **Genuinely open design question (never asked):** -1. Whether more cards exist beyond the four named (VM, word, block, message). +1. **CLOSED 2026-09-03.** Closed set — VM, word, block, message are the complete four, no new + cards for now (see H.3). -**Small design pieces still undecided:** -2. Where exactly creator-ceiling enforcement (§H.3) lands in the capsule birth flow. -3. Zuse's eligibility-list exact representation/storage (§H.5). +**Small design pieces, now resolved 2026-09-03:** +2. **CLOSED.** Creator-ceiling enforcement (§H.3) is a birth-time snapshot copy, not a live + `ACL-RECHECK`-time check — decided after a mid-conversation reversal once the live-check + approach's cross-VM lookup problem surfaced. +3. **CLOSED.** Zuse's eligibility list persists in the existing metadata-fence mechanism, as a + simple `owner_pubkey[32]` list, no extra metadata (§H.5). **Pure implementation gaps — design fully decided, nothing coded yet:** 4. `stadium_birth_hermes()`/`_artemis()` don't exist (§H.1). @@ -3873,9 +3904,17 @@ as historical record (each item already carries its own closure annotation inlin 6. `BMAPFMT`'s code edit to `block_subsystem.h`/`.c` (§F.4/§H.6 — field/API design fully closed). 7. The message card's ACL gate isn't wired onto the real `CH-REQUEST` (§H.8). -8. Creator-ceiling enforcement itself, once item 2 above is answered. +8. Creator-ceiling enforcement itself — the birth-time copy logic (§H.3, design now fully + decided as of item 2's closure above, code not written). +9. The eligibility-list's actual metadata-fence record format + the Zuse-only FORTH word to + add entries (§H.5, design now fully decided as of item 3's closure above, code not + written). **Explicitly deferred, not rejected (intentional non-goals for now):** -9. VM card multi-owner support (§H.4). -10. Elevation trigger alternates — live-console `sudo` path, pre-signed capability tickets +10. VM card multi-owner support (§H.4). +11. Elevation trigger alternates — live-console `sudo` path, pre-signed capability tickets (§H.5). + +**Remaining genuinely open design question, after this pass**: none — every design-level +question from this list is now closed. What's left is implementation (items 4–9) and +intentional deferrals (10–11).