admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-3.md §H: close gap #7 -- private-topic traffic stays ungated

Browse Source 
Checked MSG-SEND directly -- no ACL check anywhere in it today, on common
or a private topic alike. Confirmed: private-topic traffic stays ungated;
trust is established once at the handshake (CH-REQUEST/CH-ACCEPT/
CH-CONFIRM) and never re-checked per-message afterward. The message
card's scope is now final: it gates the single CH-REQUEST call, nothing
else in the messaging path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-09-02 18:57:06 -04:00
co-authored by Claude Opus 5
parent b15339ca1f
commit 26b91f1ca4
1 changed files with 18 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-3.md
+18 -8
View File
@@ -3751,13 +3751,23 @@ isn't a future design, it's already substantially built:
**Scope confirmed narrow and one-sided**: gates only "who's allowed to post on `common`
requesting a commune" — the *initiating* side of the H.7 handshake, i.e. who's allowed to
call the real `CH-REQUEST` function above. The receiving VM's decision to accept/ACK (i.e.
`CH-ACCEPT`) is **not** gated by this card. Not yet stated: whether traffic on an established
private topic (post-handshake) is gated by this card, a different mechanism, or left ungated.
`CH-ACCEPT`) is **not** gated by this card.
**Private-topic traffic gating, resolved 2026-09-02**: checked `MSG-SEND`
(`capsules/common/messaging.4th:213`, the underlying primitive both `CH-REQUEST` and any
private-topic traffic use) directly — no ACL check anywhere in it today, purely mechanical.
**Confirmed: private-topic traffic stays ungated.** Trust is established once at the
handshake, and nothing re-checks permission on every subsequent message within an
already-open private topic — consistent with this card's own narrow scope and the elevation
trigger's "keep it simple for now."
**The message card's full, final scope**: gates only the single call to `CH-REQUEST`.
Nothing else in the messaging path is ACL-gated by design.
**Implementation-gap note (2026-09-02)**: since `CH-REQUEST` is real, already-callable code
with (as far as checked) no ACL gate in front of it today, this card's job is now a concrete,
well-targeted wiring task — add the gate check to the real function — rather than a
hypothetical one waiting on future messaging infrastructure. Not yet built.
with no ACL gate in front of it today, this card's job is a concrete, well-targeted wiring
task — add the gate check to the real function — rather than a hypothetical one waiting on
future messaging infrastructure. Not yet built.
### H.9 — Gap analysis (as of 2026-09-02)
@@ -3791,9 +3801,9 @@ Explicitly open items surfaced during this capture pass, none decided yet:
`MSG-ACK-LAST`/`MSG-NACK-LAST` all exist and work today in `capsules/common/messaging.4th`).
The message card's gate is now a concrete wiring task onto a real function, not a
hypothetical one waiting on future infrastructure.
7. **Private-topic traffic gating (H.8).** Whether messages on an established private topic
(as opposed to the initiating `common` post) are gated by the message card, some other
mechanism, or left ungated entirely.
7. **CLOSED 2026-09-02 — private-topic traffic gating (H.8).** Confirmed ungated — `MSG-SEND`
has no ACL check today; trust is established once at the handshake, nothing re-checks
permission afterward. The message card's scope is now final: it gates `CH-REQUEST` alone.
8. **The `EXPIRE`/D.2 relationship.** D.2 already established "session ending = VM detach,
reuse `COOL`" — H.1's pinned/non-pinned framing should be read as refining that, not
replacing it, but the two have not been explicitly reconciled in one pass.