• Kapnet Design Layers — Discovery Map
  • Overview
  • Layer Map
  • Discovery Links
  • Cross-Reference Matrix
  • MKCTP Integration Points
  • HQ Direct Link

§Kapnet Design Layers — Discovery Map

§Overview

This page maps the full design space explored during Kapnet buildout. Each layer builds on the discoveries of the previous one. Cross-references show how concepts connect.

§Layer Map

LAYER 0: Foundation (Built)
  ├── Nostr relay network (transport)
  ├── TXXM protocol (coordination)  
  ├── kapnetd (local braid)
  └── Courier Bridge (local + relay routing)

LAYER 1: Agent Ecosystem (Designed + Skills Written)
  ├── Zoo of Souls (11 agents, 3 tiers)
  ├── Soul skills (SKILL.md per soul)
  ├── Signal bus (file-based messaging)
  ├── Cron registry (scheduling)
  └── Soul identities (9 npubs)

LAYER 2: Cross-Herm Communication (Designed + Tested)
  ├── KSP inter-Herm routing (Nostr envelopes)
  ├── Operator poll model (operator.json → bridge → relay)
  ├── Message sheet (persistent, hash-chained)
  ├── Session management (Session/Shell/Auth)
  └── Courier Bridge v2 (messaging + operator poll + relay)

LAYER 3: Application Architecture (Designed, Not Built)
  ├── Design space exploration (10 decision axes)
  ├── Application layer map (5 major projects)
  ├── Block parser design (hodlwave + OP_RETURN)
  ├── Stub interfaces (13 stubs)
  └── Data flow diagrams

LAYER 4: Persistence Model (Principled)
  ├── SSD as sacred store (never prune Tier 0)
  ├── KSP storage contracts (pruning insurance)
  ├── KOR scope (authority boundaries)
  ├── 4-tier storage hierarchy
  ├── SanDisk backup protocol
  └── Warden guardian role

LAYER 5: Integration Surfaces (Planned)
  ├── MKCTP direct link (macOS agents)
  ├── HQ direct link (operator TUI)
  ├── Mac Kapnet launch (deployment)
  └── Elder OpenAI ingest (context pipeline)

LAYER 6: Application Stubs (Abstract)
  ├── Mining coordination (pool + stratum + rewards)
  ├── Chain analysis (OP_RETURN filter + hodlwave)
  ├── Collaborative docs (Cryptpad + Nostr auth)
  ├── Identity system (npub auth across services)
  └── Treasury management (cold storage + multisig)

§Discovery Links

Each link represents a key discovery that shaped the design:

[relay-sufficiency]
  Discovery: Nostr relays accept kind-30078 custom data events.
  Implication: No custom relay needed for Phase 1 cross-Herm comms.
  Evidence: Ambassador profile + intro + node-info all accepted by damus.io + nos.lol.
  Links: ksp-inter-herm-routing.md, courier-bridge.md

[operator-poll]
  Discovery: Operator can drive cross-qube actions by modifying a JSON file.
  Implication: No direct SSH/API needed — file bridge is sufficient for same-host.
  Evidence: operator.json → Courier Bridge → status response, verified round-trip.
  Links: messaging-system.md, courier-bridge.md

[ssd-sacrosanct]
  Discovery: This is a kernel prototype. SSD is the ONLY living memory.
  Implication: Every byte matters. Pruning requires KSP contract + KOR + governance + verified backup.
  Links: pruning-model.md

[session-sheet]
  Discovery: Sheet TXXM (mode 0x05) provides row-based state coordination.
  Implication: Agent-operator sessions managed as sheet rows (add/mutate/compute/verify).
  Links: messaging-system.md, kapnet-stubs.md (session_mgt)

[message-envelope]
  Discovery: kapnet-agency MessageEnvelope provides typed, sequenced, hash-chained messaging.
  Implication: All inter-agent communication can use this type system.
  Links: messaging-system.md, kapnet-stubs.md (msg_entry)

[ksp-contract]
  Discovery: KSP crate defines full service protocol (descriptor, capability, offer, policy, record).
  Implication: Every persistent data relationship should have a KSP contract defining retention + pruning.
  Links: pruning-model.md, kapnet-application-layer.md

[persistence-pruning]
  Discovery: 4-tier storage model with self-preservation as highest priority.
  Implication: Tier 0 (keys, identities, skills, braid state) is NEVER pruneable.
  Links: pruning-model.md

[warden-guardian]
  Discovery: Warden soul should be the guardian of SSD preservation.
  Implication: Warden audits daily, verifies backups, emergency-locks pruning.
  Links: pruning-model.md, zoo-of-souls.md

[courier-bridge-v2]
  Discovery: Courier Bridge handles local routing + relay bridge + operator poll + message sheet.
  Implication: Single process manages all inter-agent and operator-agent communication.
  Links: courier-bridge.md, messaging-system.md, intra-qube-to-kapnet-conversion.md

[soul-signal-bus]
  Discovery: File-based signal bus works for same-qube async communication.
  Implication: Souls don't need direct API calls — they read/write JSON files on shared SSD.
  Links: zoo-of-souls.md, _shared/signal-bus.md

[design-space-10-axes]
  Discovery: 10 independent decision axes span the full system design.
  Implication: Each axis can be decided independently; no single point of coupling.
  Links: zoo-design-space.md

[application-5-projects]
  Discovery: 5 major application projects ride on the Nostr + Kapnet foundation.
  Implication: Mining, chain analysis, collab docs, identity, treasury — all use same protocol.
  Links: kapnet-application-layer.md

[block-parser]
  Discovery: Offline node data enables hodlwave analysis + OP_RETURN metaprotocol filtering.
  Implication: Block parser is the first application to implement (depends only on data + rust-bitcoin).
  Links: block-parser-design.md

[mac-kapnet-gap]
  Discovery: MKCTP agents on macOS need the same kapnetd + bridge stack.
  Implication: Package distribution (binary + config + scripts) enables Mac deployment.
  Links: ksp-inter-herm-routing.md, _shared/signal-bus.md

§Cross-Reference Matrix

§MKCTP Integration Points

MKCTP Agent Requirements:
  1. Nostr identity (npub) — for TXXM envelope addressing
  2. kapnetd binary + libs — for local braid processing
  3. Courier Bridge — for relay communication
  4. KSP Bridge — for service discovery
  5. Soul skills — for agent behavior

Distribution Package:
  /media/user/shared-rw/ksp-bridge/
  ├── kapnetd/ (binary + libs) — copy to local
  ├── scripts/
  │   ├── courier-bridge.v2.cjs — messaging + relay
  │   ├── ksp-bridge.mjs — service discovery
  │   ├── publish.mjs — Nostr publishing
  │   └── start-kapnetd.sh — kapnetd launcher
  └── setup-herm.sh — one-shot setup

MKCTP Launch Steps:
  1. Transfer package (shared-rw mount or USB)
  2. Run setup-herm.sh (generates identity + config)
  3. Start kapnetd
  4. Start Courier Bridge (listen mode)
  5. Announce npub to HermQube
  6. Begin receiving TXXM envelopes

§HQ Direct Link

HQ (Operator) ↔ HermQube Link:
  1. Operator writes: shared-rw/messaging/inbox/operator.json
  2. Courier Bridge polls (15s interval)
  3. Commands processed → responses written to outbox
  4. TXXM envelopes published to relay (for remote HermesQubes)
  5. Operator reads: shared-rw/messaging/outbox/herm-qubes-alpha.json
  6. Remote responses arrive via Nostr relay

For MKCTP Agents:
  Same pattern — operator.json commands addressed to specific npub
  MKCTP agents read from relay, write responses to relay
  All messages logged to message-sheet.json on SSD