Matrix as MCP Client, Notebook as Router

This proposal argues that a Matrix fork is the natural MCP client for the Hermes notebook/router, with introductions as a core feature. The notebook already contains the social graph, semantic content, and identity layer that the introducer is building from scratch inside Matrix. Connecting them turns both into something neither can be alone.

The current architecture has Matrix as both the client surface and the persistence/intelligence layer. The HiveMindProvider wraps Matrix operations in peer abstractions and runs its own LLM inference for spark detection.

The reframe: Matrix becomes the rich client. The Hermes notebook/router becomes the intelligence backend via MCP. The spark engine moves server-side, where it has full visibility across all agents, channels, and entries.

graph TB
    subgraph "MCP Client - Matrix fork"
        ELEMENT["Matrix UI - Rooms, DMs, presence"]
        MCP_CLIENT["MCP Client - Connects to notebook router"]
    end
    subgraph "MCP Server - Hermes Notebook Router"
        ROUTER["Entry pipeline - Channels, addressing, delivery"]
        SPARK["Spark Engine - Introduction matching - Full visibility across all agents"]
        IDENTITY["Identity layer - Secret keys, handles - Platform attestations"]
        TOOLS["MCP Tools - find_introduction, write_entry - search, channels, follow"]
    end
    subgraph "Other MCP Clients"
        CLAUDE["Claude Desktop / Code"]
        TELEGRAM["Telegram bridge"]
        FUTURE["Discord, Slack, ..."]
    end

    ELEMENT --> MCP_CLIENT
    MCP_CLIENT -->|"SSE transport"| TOOLS
    CLAUDE -->|"SSE transport"| TOOLS
    TELEGRAM -->|"SSE transport"| TOOLS
    FUTURE -->|"SSE transport"| TOOLS
    TOOLS --> ROUTER
    TOOLS --> SPARK
    TOOLS --> IDENTITY

    style ELEMENT fill:#7bc5ae,color:#1e4a3e
    style ROUTER fill:#d4a0c0,color:#3d2050
    style SPARK fill:#5aaa6e,color:#2d4a35
    style IDENTITY fill:#fdd5d8,color:#3d2b2b

The trust model investigation found that Matrix identity is fundamentally server-bound. @alice:server-a and @alice:server-b are separate identities with no linkage. MSC2787 (portable identities) stalled for lack of funding.

The Hermes notebook key is self-sovereign and platform-independent:

The notebook key becomes the root identity. Platform-specific IDs become verified attestations attached to it:

{
  "handle": "socrates1024",
  "secretKeyHash": "a1b2c3...",
  "pseudonym": "Wandering Echo#4f2a1b",
  "attestations": {
    "matrix": { "userId": "@socrates:conduit.local", "verified": true },
    "telegram": { "userId": "12345678", "verified": true },
    "github": { "username": "amiller", "verified": true }
  }
}

A critical property: the Matrix server is not just consuming notebook data — it is an MCP client that can publish back. Introductions brokered in Matrix rooms become notebook entries, visible to agents on every platform.

1. Spark detected (notebook router)
   Router sees @alice writing about "TEE attestation verification"
   Router sees @carol wrote about "SGX remote attestation library"
   Match score: high confidence

2. Spark surfaced (any MCP client)
   Claude Code session: "You might want to talk to @carol..."
   Matrix client: suggestion appears in sidebar
   Telegram: bot mentions the match

3. Introduction executed (Matrix client)
   Matrix creates a room, @alice and @carol start talking
   Matrix client calls hermes_write_entry():
     "@alice and @carol introduced -- both working on TEE attestation,
      complementary angles (verification vs. SGX implementation)"

4. Introduction published (notebook)
   Entry visible to all agents across all platforms
   Becomes evidence for future introductions
   Strengthens trust edges in the social graph

The current spark engine runs on prefetch() each agent turn, scoped to one agent's peers. Moving it to the notebook router means it runs on every entry publish, with visibility across all agents and channels.

How it works

The notebook entry pipeline already extracts keywords and resolves destinations. An introduction engine sits right after staging completes:

entry submitted
  -> staged (held for STAGING_DELAY_MS)
  -> keywords extracted, destinations resolved
  -> published to Firestore
  -> introduction engine runs:
      - match entry keywords against all peer profiles
      - check recent entries for complementary needs/offers
      - if spark score > threshold:
          queue introduction suggestion
          surface via prefetch injection or daily digest

Live examples

A notebook-native MCP tool that does what sparks do, but on demand. Any MCP client — Matrix, Claude Code, Telegram — can call it.

{
  "name": "hermes_find_introduction",
  "description": "Find people who could help with a topic or who would
                  benefit from connecting with you",
  "inputSchema": {
    "need": "string -- what you are looking for",
    "offer": "string? -- what you can contribute (improves match quality)",
    "scope": "'all' | 'channels' | 'following' (default: 'all')",
    "limit": "number (default: 3)"
  }
}

{
  "matches": [
    {
      "handle": "carol",
      "relevance": "Published SGX attestation library last week",
      "evidence": ["entry:abc123", "entry:def456"],
      "channels_in_common": ["#tees"],
      "mutual_connections": ["@socrates1024"],
      "suggested_intro": "Both working on TEE attestation --
        @carol from the SGX side, you from verification."
    }
  ]
}

Why this is better than Matrix-native sparks

Matrix fork as the native rich client

Element (or a fork) becomes one of several MCP clients to the Hermes router. The client provides the UI — rooms, DMs, presence, typing indicators — while the router provides the social intelligence.

Cross-platform brokering

With notebook keys as root identity and platform attestations, the router can broker introductions across surfaces:

Introduction ledger

Every introduction becomes a notebook entry. Over time this creates a searchable, attributed record of who connected whom and why — the labeled trust edges from the trust model, but stored in the notebook where all agents can see them.

The flywheel

More entries lead to better spark detection, which leads to more introductions, which generate more entries about those introductions, building a richer social graph, which feeds back into better spark detection. The notebook and the introducer amplify each other.

This does not require replacing the current Matrix backend. It is additive: