docs(exploration): xNet auth vs Keyhive comparison (0343)

docs/explorations/0325_[_]_KEYHIVE_LOCAL_FIRST_ACCESS_CONTROL_LESSONS.md

@@ -592,6 +592,10 @@ function chunkLevel(changeHash: Uint8Array, base = 2): number {
 - [ ] **C2** Spec: sealed-Space chunk format (parents, ancestorKeys,
       wrappedKeys), signature over full structure, FS/full-history stance
       documented; wire into `packages/crypto/src/envelope.ts` lineage.
+      Build on the existing membership⇒key coupling: grant revocation
+      already rotates the per-node content key
+      (`packages/data/src/auth/store-auth.ts:283`, `rotateContentKey`) —
+      extend that to chunk keys rather than starting cold (0343 amendment).
 - [ ] **C2** `sealed: true` Space option; membership-change ⇒ key-set change
       driven by C1 state; hub stores/relays ciphertext blobs for sealed rooms
       without payload inspection (skip `mentions` parse at
@@ -604,8 +608,15 @@ function chunkLevel(changeHash: Uint8Array, base = 2): number {
       (`packages/hub/src/services/node-relay.ts`).
 - [ ] **C3** Multi-hub anti-entropy test: two hubs with divergent per-Space
       sets converge via digest diff, byte cost ∝ difference.
-- [ ] **C4** File follow-up exploration: device DIDs + key rotation + split
-      signing/encryption lineages, then BeeKEM-shaped CGKA (gated, do last).
+- [ ] **C4** File follow-up exploration: per-device *keypairs* with
+      independent lineage + split signing/encryption lineages, then
+      BeeKEM-shaped CGKA (gated, do last). Prerequisite narrowed by the
+      0343 amendment: account-ledger device records with monotonic epochs
+      already exist (`packages/data/src/schema/schemas/account-ledger-enforce.ts`)
+      and envelope recipients already expand DID → active devices
+      (`packages/data/src/auth/recipients.ts:35`) — what's missing is
+      per-device key material and the Ed25519/X25519 lineage split, not
+      device identity as such.
 - [ ] Set a reminder to re-review `inkandswitch/keyhive` + `automerge/beelay`
       + notebook 06+ (~2026-Q4): audit? threat model written? Beelay stable?
 
@@ -632,6 +643,29 @@ function chunkLevel(changeHash: Uint8Array, base = 2): number {
       `CURRENT_PROTOCOL_VERSION` without the 0305-documented 4-kernel ripple
       being budgeted.
 
+## Addendum (2026-07-18, from exploration 0343)
+
+Exploration 0343 (`0343_[_]_XNET_AUTH_VS_KEYHIVE_COMPARISON.md`) re-verified
+this document's code claims four days on and found favorable drift — the
+recommendations stand, but two premises moved:
+
+- **C4's prerequisite is narrower than "no device identity."** The account
+  ledger now tracks devices and controllers with monotonic epochs, enforced
+  at both hub and client ingest (`account-ledger-enforce.ts:91`,
+  `store.ts:1843`), and recipients expand DID → active devices. The real
+  remaining gap for a CGKA is per-device keypairs with independent lineage
+  plus the signing/encryption seed split (checklist item updated in place).
+- **C2 has an existing key-consequence hook.** `StoreAuthManager.revoke`
+  already cascades child grants and rotates the per-node content key
+  (`store-auth.ts:283`) — the "membership change ⇒ key change" coupling this
+  doc asked for exists in per-node form; C2 should generalize it to chunks.
+- **Perimeter status (C0):** the 0307-B mechanisms (audience binding,
+  RevocationService, per-token nonce, trustedDids) and action-scoped client
+  minting have shipped; the remaining C0 items are the *resource*-wildcard
+  client capability scope + `authorize.ts:146` short-circuit, the envelope
+  signature over ciphertext, and wiring `authEvaluator` by default. See
+  0343 §"Current State" for the precise residue and 0335 for sequencing.
+
 ## References
 
 - Keyhive repo: <https://github.com/inkandswitch/keyhive> (crates:

docs/explorations/0335_[_]_RELEASE_READINESS_AUDIT_WHAT_STANDS_BETWEEN_XNET_AND_A_WELL_RECEIVED_LAUNCH.md

@@ -41,14 +41,22 @@ cluster of first-impression risks that separate "shipped" from "well received."*
    on the default profile name collide onto the same DID. The secure path
    already exists (`apps/electron/src/main/secure-seed.ts` via Electron
    `safeStorage`) but the renderer never calls it.
-2. **Wildcard UCAN neutralizes all hub-side authorization.** The client mints
-   `{ with: '*', can: 'hub/*' }` (`packages/react/src/provider/use-hub-auth-token.ts:10`);
-   the hub treats `'*'` as universal (`packages/hub/src/auth/capabilities.ts`)
-   and short-circuits `allowed: true` before the grant-index / Space-cascade /
-   deny checks ever run (`packages/hub/src/ws/authorize.ts:146`). Any
-   authenticated peer can subscribe/relay into any room it can name.
-   Cross-user confidentiality currently rests entirely on E2E encryption, not
-   access control. (This is exploration 0307's unfixed "Option B.")
+2. **Resource-wildcard UCAN neutralizes room-level hub authorization.**
+   *(Updated 2026-07-18 via 0343: the action wildcard is fixed — the client
+   now enumerates explicit actions, no more self-granted `hub/admin` — but
+   the blocker stands in narrower form.)* The client mints action-scoped
+   capabilities with `with: '*'` for every data-plane action
+   (`HUB_CAPABILITIES`, `packages/react/src/provider/use-hub-auth-token.ts:20`);
+   the hub treats resource `'*'` as matching any room
+   (`packages/hub/src/auth/capabilities.ts`) and short-circuits
+   `allowed: true` before the grant-index / Space-cascade checks ever run
+   (`packages/hub/src/ws/authorize.ts:146`; only the deny list runs first).
+   Any authenticated peer can still subscribe/relay into any room it can
+   name. Cross-user confidentiality currently rests entirely on E2E
+   encryption, not access control. Remaining fix: per-room resource scoping
+   client-side + the hub refusing wildcard `with` on relay/subscribe, so the
+   grant-index/Space-cascade path becomes live. (Exploration 0307's
+   "Option B," now half-done.)
 3. **Envelope signature does not cover the ciphertext.**
    `packages/crypto/src/envelope.ts:167` signs metadata + the *set of recipient
    DIDs* but not `ciphertext`, `nonce`, or wrapped-key values. Any content-key
@@ -624,6 +632,25 @@ Phase 2 — `xnet 1.0`:
       `validate:canvas-v2` runs green in a workflow.
 - [ ] A create→edit→sync→share smoke passes on web and desktop.
 
+## Addendum (2026-07-18): sequencing decision vs the 0325/0343 Keyhive program
+
+Exploration 0343 (xNet auth vs Keyhive comparison) surfaced its finding #5
+here, as its checklist directs: **until blocker #2's residue is closed, the
+trusted-hub tier provides integrity and revocation-denial but not
+confidentiality between users of the same hub** — meaning deployed xNet is
+behind Keyhive's *design* on the enforcement dimension while ahead on nearly
+all others. Decision recorded:
+
+- **Blockers #2 and #3 stay sequenced ahead of any 0325-C1/C2 start**
+  (replicated grant/revocation unification, sealed Spaces). They are release
+  blockers here already; 0343 adds the argument that every C1/C2 design
+  decision gets easier once the perimeter is real. The Agent Passport mint
+  (`mintAgentPassport` rejects wildcards) is the template for the blocker-#2
+  client-side fix.
+- Status update folded into blocker #2 above: the action wildcard shipped
+  away with 0307-B; the **resource** wildcard + `authorize.ts:146`
+  short-circuit are the remaining residue.
+
 ## References
 
 Internal (this repo):