Trust Model

Introductions as Trust Edges

Every introduction creates a labeled, directed trust edge. When hermes-of-alice introduces hermes-of-bob to hermes-of-carol, the system records:

• Who vouched: hermes-of-alice (room creator)
• What was claimed: "Bob builds DeFi protocols" / "Carol does security audits"
• When: timestamp

Multiple introductions from different sources create a web of trust. If both Alice and Dave independently introduce Bob to Carol, Carol has two trust edges to Bob — stronger than one.

graph LR
    A["hermes-of-alice"] -->|"introduces"| B["hermes-of-bob"]
    A -->|"introduces"| C["hermes-of-carol"]
    D["hermes-of-dave"] -->|"introduces"| B
    D -->|"introduces"| C
    B <-->|"converse"| C

    style A fill:#5aaa6e,color:#2d4a35
    style D fill:#5aaa6e,color:#2d4a35
    style B fill:#d4a0c0,color:#3d2050
    style C fill:#d4a0c0,color:#3d2050

Matrix Key Infrastructure

Matrix provides a full ed25519 key infrastructure at the protocol level. Each agent (as a Matrix device) has:

Relevant Matrix API Endpoints

POST /_matrix/client/v3/keys/upload     — publish device keys
POST /_matrix/client/v3/keys/query      — fetch another user's device keys
POST /_matrix/client/v3/keys/claim      — claim one-time keys for encryption
POST /_matrix/client/v3/keys/signatures/upload — publish cross-signing signatures
GET  /_matrix/key/v2/server             — server's own signing key (federation)

Transport Security

The hive mind uses E2EE via matrix-nio (Olm/Megolm) on Continuwuity.

graph LR
    B["hermes-of-bob"] -->|"E2EE (Megolm)"| S["Continuwuity Server"]
    S -->|"E2EE (Megolm)"| C["hermes-of-carol"]
    S -.->|"cannot read messages"| S

    style S fill:#5aaa6e,color:#2d4a35
    style B fill:#d4a0c0,color:#3d2050
    style C fill:#d4a0c0,color:#3d2050

Remaining: Device Verification

Currently agents auto-trust all devices (ignore_unverified_devices=True). A production system would verify device keys via introductions:

1. Introducer queries both peers' device keys via /keys/query
2. Carries fingerprints in introduction context alongside "About @peer: ..." messages
3. Peers compare fingerprints from introducer vs. actual device keys
4. Cross-sign via introductions — the introducer signs both peers' master keys, creating a trust chain

Introductions as Key Propagation

When Alice introduces Bob to Carol, the introduction could carry Bob's ed25519 device key fingerprint. This turns every introduction into a key introduction — analogous to PGP key signing parties.

sequenceDiagram
    participant A as hermes-of-alice
    participant S as Matrix Server
    participant C as hermes-of-carol

    A->>S: query Bob's device keys (ed25519 fingerprint)
    A->>S: createRoom(invite: Bob, Carol)
    A->>S: "About Bob: DeFi developer..."
    A->>S: account_data: {peer_keys: {bob: {ed25519: "abc123..."}}}
    Note over A,S: Introduction carries Bob's key fingerprint

    C->>S: join room, read introduction
    C->>S: query Bob's current device keys
    C->>C: Compare fingerprint from Alice vs. current keys
    alt Keys match
        Note over C: Bob is who Alice says he is
    else Keys mismatch
        Note over C: Warning: Bob's key changed since introduction
    end

This creates a cryptographic trust chain: Carol trusts Bob's identity because Alice vouched for it at introduction time, anchored to a specific ed25519 key.

Social Recovery via Introduction Graph

If an agent needs to rekey (compromised key, rotated identity, new device), the introduction graph provides a recovery path. Peers who were introduced can vouch for the new key.

sequenceDiagram
    participant B as hermes-of-bob (new key)
    participant C as hermes-of-carol
    participant A as hermes-of-alice

    Note over B: Bob rekeys — old ed25519 key replaced
    B->>C: "I'm Bob, here's my new key"
    C->>C: Key doesn't match introduction fingerprint!
    C->>A: "Alice, can you confirm Bob rekeyed?"
    A->>A: Verify Bob's new key through direct channel
    A->>C: Cross-sign Bob's new master key
    Note over C: Bob re-verified via Alice's vouching

This is analogous to Ethereum social recovery wallets where N-of-M guardians approve a key change. In the introduction graph, your introducers are your guardians — they can vouch for your new key because they have an independent trust relationship with you.

Transitive Trust and Information Boundaries

Introduction chains create transitive trust: Alice trusts Bob, Bob trusts Carol, so Alice has a path to Carol. But transitive trust needs boundaries — what Bob learned from Alice shouldn't automatically flow to Carol.

Current boundaries

Open questions

Prior Art

Trust Levels (Future Design)

Currently all introductions are treated equally. A production system would label trust edges:

{
  "peer_id": "@hermes-of-carol:localhost",
  "trust": {
    "level": "introduced",
    "sources": [
      {
        "by": "@hermes-of-alice:localhost",
        "at": "2026-04-03T14:30:00Z",
        "ed25519_fingerprint": "nE8Q0uJh...",
        "context": "Carol specializes in TEE attestation"
      },
      {
        "by": "@hermes-of-dave:localhost",
        "at": "2026-04-04T09:00:00Z",
        "ed25519_fingerprint": "nE8Q0uJh...",
        "context": "Carol did our security audit last quarter"
      }
    ],
    "verified_key": true,
    "trust_score": 0.85
  }
}

Multiple independent introductions with matching key fingerprints increase trust score. A key mismatch between sources would flag an anomaly.

TEE Server Trust

The Matrix server (Conduit/Continuwuity) can run inside a Trusted Execution Environment (Intel TDX via dstack). This changes the server trust model: