---
title: "DeepSeek Harness mit Buzz verbinden: Das Nostr-Gateway"
description: "Integrieren Sie DeepSeek Harness über eine Nostr-Bridge in Block Buzz: NIP-42-Auth, In-Place-Streaming-Edits und kanalbezogene Agenten-Workspaces konfigurieren."
canonical_url: "https://techvoyage.dev/de/article/bringing-buzz-to-deepseek-harness"
last_updated: "2026-10-20T09:53:49.698Z"
---

![Übersicht über das mit einem Block Buzz-Kanal verbundene DeepSeek Harness Nachrichten-Gateway](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-nostr-gateway-overview.webp)

Das DeepSeek Harness (DSH) Plugin, **dsh-message-gateway**, erweitert den DeepSeek Harness Assistenten auf verschiedene Messaging-Plattformen wie Discord, Telegram und WeChat. Das Plugin-Repository wurde geforkt und erweitert, um die Plattform **Block's Buzz selbst hosten: Workspace für Mensch & KI-Agenten** zur Liste hinzuzufügen. Das geforkte Repository ist auf GitHub unter [https://github.com/Tech-Voyage-Dev/dsh-message-gateway](https://github.com/Tech-Voyage-Dev/dsh-message-gateway) verfügbar.

<article-card description="Lernen Sie, wie Sie das Nostr-Relay Block's Buzz auf einem Ubuntu VPS hinter Cloudflare selbst hosten. Ein sicherer Workspace für Menschen und KI-Agenten." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/DE-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Eine Premium-Technologiekarte im Format 16:9 mit tiefblauen und orangefarbenen Akzenten, die zeigt, wie man das Buzz-Relay von Block auf einem Ubuntu-VPS selbst hostet, mit einem klaren glassmorphic Panel mit zentrierter Typografie." label="Voraussetzungsleitfaden" min-read="12" title="Block's Buzz selbst hosten: Workspace für Mensch & KI-Agenten" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues">



</article-card>

Der DSH-Assistent tritt einem Buzz-Relay als vollwertiges Mitglied bei, empfängt Direktnachrichten (DMs) sowie Kanalnachrichten, in denen er @erwähnt wird, und antwortet über dieselbe kanalbezogene Agenten-Pipeline, die auch von der Weboberfläche genutzt wird.

## Architektur des dsh-message-gateway Plugins

Die Architektur des **dsh-message-gateway** Plugins gliedert sich in zwei Kernbereiche:

- **Host** (Node): `gateway-store` (Zugangsdaten in `~/.dsh/gateway.json`), `platforms.ts` (Plattformdefinitionen und Verbindungstests), `routes.ts` (`/gateway/*` Endpunkte) und `bridge-manager.ts` (die residenten Bridges: unabhängige Agentensitzungen pro Chat und gestreamte Antworten).
- **Client** (Browser): Die Seite "**Message platforms**" in der Seitenleiste, auf der Sie Zugangsdaten hinterlegen, Verbindungen testen und den Status überwachen.

Die Anbindung einer neuen Plattform umfasst folgende Schritte:

1. **Eine Bridge-Klasse**: Stellt `start/stop/status` sowie einen `onText(text, frame)` Callback bereit, analog zu `wecom-bridge.ts`.
2. **Bridge-Manager-Verdrahtung**: Wiederverwendung der bestehenden Chat-Pipeline (`ensureAgentForKey` + `pendingMap`) unter Einbindung der Antwort-Senke der Plattform.
3. **Speicher- und Routen-Anbindung**: In `/gateway/save` und `/gateway/delete`: **Das Speichern von Zugangsdaten startet die Bridge, das Löschen stoppt sie** — ergänzt durch ein `autoStartXxx`-Flag, damit `dsh web` beim Systemstart automatisch neu verbindet.

## Buzz-Bridge-Implementierung: Nostr-Protokoll & Event-Lebenszyklus

**DeepSeek Harness** wurde direkt verwendet, um die Buzz-Bridge zu implementieren. Die Umsetzung erfüllt die folgenden Nostr-Protokollspezifikationen:

<table>
<thead>
  <tr>
    <th>
      <strong>
        Transport
      </strong>
    </th>
    
    <th>
      Ein NIP-42-authentifizierter WebSocket; Standard <code>
        ws://localhost:3000
      </code>
      
      ; <code>
        http(s)://
      </code>
      
       wird zu <code>
        ws(s)://
      </code>
      
       normalisiert
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Authentifizierung
      </strong>
    </td>
    
    <td>
      AUTH-Event <code>
        kind 22242
      </code>
      
      , Tags <code>
        [["relay", url], ["challenge", challenge]]
      </code>
      
      , leerer Inhalt, signiert mit dem Agenten-Schlüssel
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Abonnements
      </strong>
    </td>
    
    <td>
      <strong>
        Kanalbezogen
      </strong>
      
      : <code>
        REQ {"kinds":[9], "#h":[<uuid>]}
      </code>
      
       — ein REQ pro Kanal. Ein globales <code>
        kinds:[9]
      </code>
      
       REQ erhält EOSE, liefert aber keine Events aus; Multi-Wert <code>
        #h
      </code>
      
       funktioniert <strong>
        nicht
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Erkennung (Discovery)
      </strong>
    </td>
    
    <td>
      Historisches <code>
        REQ {kinds:[39000]}
      </code>
      
       für Kanal-Metadaten (<code>
        type == "dm"
      </code>
      
       markiert Direktnachrichtenkanäle)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Mitgliedschaft
      </strong>
    </td>
    
    <td>
      Live <code>
        REQ {kinds:[44100,44101], "#p":[unser pubkey], since: now-60s}
      </code>
      
       — 44100 = hinzugefügt, 44101 = entfernt, mit <code>
        p
      </code>
      
      +<code>
        h
      </code>
      
      ; aktualisiert Abonnements <strong>
        ohne Reconnect
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Chat-Events
      </strong>
    </td>
    
    <td>
      <code>
        kind 9
      </code>
      
       mit Tags <code>
        ["h", channel]
      </code>
      
      , optional <code>
        ["e", replyTo]
      </code>
      
      , <code>
        ["p", mention]
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        In-Place-Edits
      </strong>
    </td>
    
    <td>
      <code>
        kind 40003
      </code>
      
       mit <code>
        h
      </code>
      
       + <code>
        e
      </code>
      
      →Ziel; ersetzt Inhalt; Relay-Limit 64 KB → Nutzlasten ≤ 60.000 B halten; lange Antworten werden aufgeteilt — Chunk 0 nutzt das Edit, Überhang folgt als <code>
        kind 9
      </code>
      
       Thread-Nachricht (<code>
        e
      </code>
      
      →Root)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CLOSED-Frames
      </strong>
    </td>
    
    <td>
      <code>
        auth-required
      </code>
      
       vor AUTH ist normaler Bootstrap (AUTH abschließen, Subs neu öffnen); nach AUTH → begrenzter Neuversuch (3 Versuche, 0/1/2 s Backoff); Reconnect baut alles neu auf
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Relay-Limits
      </strong>
    </td>
    
    <td>
      ≤ 2000 historische Events pro Abonnement, chronologisch absteigend (neueste zuerst), selbst mit <code>
        since
      </code>
      
      -Filter
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Erwähnungs-Filter
      </strong>
    </td>
    
    <td>
      Verarbeitet eingehende <code>
        kind 9
      </code>
      
       nur wenn: (a) <code>
        p
      </code>
      
      -Tag unseren Pubkey enthält, (b) Kanal ein DM ist, oder (c) <code>
        e
      </code>
      
      -Root unser eigenes Event ist. Eigener Pubkey wird ignoriert (Schleifenschutz)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Ausgehende Erwähnungen
      </strong>
    </td>
    
    <td>
      Ausgehender Text wird unverändert veröffentlicht — das Relay prüft keine <code>
        @
      </code>
      
      -Token; <code>
        p
      </code>
      
      -Tags enthalten den ursprünglichen Autor + bis zu 7 weitere erwähnte Pubkeys (max. 8)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Direktnachrichten (DM)
      </strong>
    </td>
    
    <td>
      Relay-spezifische Klartext-Kanäle (<code>
        type: "dm"
      </code>
      
       Metadaten) — keine NIP-04/44-Verschlüsselung in dieser Bridge
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Anhänge (Eingehend)
      </strong>
    </td>
    
    <td>
      NIP-92 <code>
        imeta
      </code>
      
       (<code>
        url
      </code>
      
      , <code>
        sha256
      </code>
      
      , <code>
        m
      </code>
      
      ) → Standard-HTTP(S)-Download, SHA-256-Prüfung, 20 MB Limit, max. 4 pro Nachricht; ausgehende Bilder werden nicht unterstützt
    </td>
  </tr>
</tbody>
</table>

Das folgende Diagramm veranschaulicht den Bootstrap-Ablauf der Buzz-Bridge:

![Sequenzdiagramm zur Veranschaulichung des Bootstrap- und NIP-42-Authentifizierungsprozesses der Buzz-Bridge](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-bootstrap.webp)### Echtzeit-Streaming über Nostr In-Place-Edits (Kind 40003)

Da Nostr keine native Tippanzeige besitzt und Events append-only gespeichert werden, **simuliert die Buzz-Bridge Streaming über In-Place-Edits**:

![Ablaufdiagramm der In-Place-Bearbeitung zur Simulation gestreamter Antworten mittels Kind-40003-Events](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-reply.webp)- *Die Buzz-Bridge veröffentlicht zunächst ein temporäres Platzhalter-Event kind 9, schreibt dieses kontinuierlich mit ratenlimitierten kind 40003 In-Place-Edits fort und setzt den finalen Edit, sobald der Agent die Generierung beendet hat. Dies entspricht dem bewährten Muster von Telegram- und Discord-Bridges.*

### Einbindung von DeepSeek Harness Workspaces über Chat-Befehle

Die "Workspaces"-Funktion in der DSH-Weboberfläche basiert auf dem `workspaceRegistry`-Dienst (`@deepseek-ai/dsh-workspace`):

```typescript
const existing = await ctx.workspaceRegistry.resolveByPath(request.path);
```

Die Buzz-Bridge stellt den Chat-Befehl `/workspace <ordner>` bereit, der ein bestehendes Verzeichnis in DSH registriert. Jede neue über das Gateway initiierte Sitzung wird diesem Ordner zugeordnet und erscheint in der Weboberfläche.

![Architektur der Registrierung von DeepSeek Harness-Workspaces über Chat-Befehle](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace.webp)Drei zentrale Entwurfsentscheidungen:

- **Ordnerwechsel = Neue Sitzung.** Der Parameter `cwd` wird bei der Initialisierung im Sitzungs-Header hinterlegt und kann nachträglich nicht geändert werden.
- **Ordner muss bereits existieren.** Der Aufruf `create` weist nicht vorhandene Pfade ab.
- **Sicherheitsrelevanter Befehl.** Jede Sitzung läuft unter einer **Auto-Approve**-Richtlinie und gewährt Dateizugriff auf das Zielverzeichnis.

## Schritt-für-Schritt Installations- und Konfigurationsanleitung

1. Führen Sie folgende Befehle im Terminal aus:

```bash
dsh plugin --profile web add https://github.com/Tech-Voyage-Dev/dsh-message-gateway.git

# Start DSH web
dsh web
```

1. Sobald die DSH-Weboberfläche im Browser geladen ist, klicken Sie auf das Symbol "**Message platforms**":

![Seitenleiste der DeepSeek Harness-Weboberfläche mit hervorgehobenem Message platforms-Menü](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-message-platforms-sidebar-icon.webp)

1. Wählen Sie "**Buzz**" im linken Navigationsbereich:

![Konfigurationsbereich der Buzz-Bridge im DeepSeek Harness Nachrichten-Gateway](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-message-gateway-buzz-config-panel.webp)

1. Klicken Sie auf "**Generate keypair**", um ein Nostr-Schlüsselpaar zu generieren. Kopieren Sie den öffentlichen Schlüssel `npub` an einen sicheren Ort.
2. Tragen Sie die **Relay URL** sowie die **Channels** (die Allowlist der zu abonnierenden Kanal-UUIDs) ein.
3. Klicken Sie auf die Schaltfläche "**Save**".

Das Speichern des Formulars sichert die Zugangsdaten und **startet die Bridge**. Der private Schlüssel `nsec` wird als vertrauliches Geheimnis behandelt und verbleibt ausschließlich in `~/.dsh/gateway.json`.

### Agenten-Schlüsselpaar im Buzz Nostr-Relay registrieren

**Fügen Sie den DSH-Assistenten dem Relay als Mitglied hinzu.** Verwenden Sie dazu den zuvor generierten `npub`:

```bash
docker compose exec relay buzz-admin add-member --pubkey npub123123123
```

**Weisen Sie den Assistenten einem bestimmten Kanal zu.** Die Mitgliedschaft im Relay allein macht den Agenten in Kanälen noch nicht sichtbar oder durchsuchbar. Beim Ausführen dieses Schritts mit `buzz-cli` muss der Parameter `--pubkey` im **HEX**-Format angegeben werden, nicht als npub (der Befehl `buzz-admin add-member` gibt den entsprechenden HEX-Schlüssel aus):

```bash
buzz channels add-member --channel <CHANNEL_UUID> --pubkey <AGENT_HEX> --role member
```

<article-card description="Schritt-für-Schritt-Anleitung zur Installation und Konfiguration von buzz-cli zur Verwaltung von Nostr-Kanälen, Mitgliedsschlüsseln und Berechtigungen für KI-Agenten." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/DE-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Eine Premium-Technologiekarte im Format 16:9 mit tiefblauen und orangefarbenen Akzenten, die zeigt, wie man das Buzz-Relay von Block auf einem Ubuntu-VPS selbst hostet, mit einem klaren glassmorphic Panel mit zentrierter Typografie." label="CLI-Anleitung" min-read="5" title="So installieren und verwenden Sie buzz-cli" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues#install-buzz-cli">



</article-card>

Aktualisieren Sie das Profil des DSH-Assistenten im Nostr-Relay auf einen aussagekräftigen Anzeigenamen mittels `buzz-cli`:

![Aktualisierung des Profilnamens des DSH-Assistenten auf dem Nostr-Relay mit buzz-cli](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-assistant-buzz-cli-profile-update.webp)

Senden Sie ein **Wave** (die Direktnachrichten-Begrüßung in Buzz) an den Assistenten. Die Antwort bestätigt die Betriebsbereitschaft:

![Verbindungstest durch Senden eines Wave-DMs an den DeepSeek Harness-Assistenten in Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-dm-wave-greeting-reply.webp)

*Senden eines Wave als DM an den DSH-Assistenten — die Bridge antwortet prompt.*

### Lokalen Ordnerzugriff mit `/workspace` aktivieren

Da die Einstellung `allowWorkspace` standardmäßig auf `false` gesetzt ist, wird der Befehl `/workspace` zunächst abgewiesen:

![Fehlermeldung bei der Ablehnung des Workspace-Befehls bei deaktiviertem allowWorkspace](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-rejected-error.webp)

Aktivieren Sie die Option in `~/.dsh/profiles/web/cordis.patch.yml` und starten Sie `dsh web` neu:

```yml
- id: ui-message-gateway
  config:
    allowWorkspace: true
```

Nach dem Neustart:

![Erfolgreiche Bestätigungsmeldung nach Ausführung des Workspace-Registrierungsbefehls in Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-success-confirmation.webp)

Wichtiger Hinweis: Die Konfiguration geht davon aus, dass der Workspace-Ordner (`TechVoyage` in den Screenshots) im Standard-Benutzerverzeichnis liegt. Geben Sie andernfalls den vollständigen absoluten Pfad an. Jede neue über Buzz gestartete Sitzung wird auch in der Weboberfläche von DeepSeek Harness aufgeführt.

![DeepSeek Harness-Weboberfläche mit der aus Buzz synchronisierten aktiven Workspace-Sitzung](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-synced-workspace-session.webp)

### Verfügbare Befehle in Buzz

Alle von anderen Plattformen bekannten Befehle stehen auch in Buzz uneingeschränkt bereit:

<table>
<thead>
  <tr>
    <th>
      Befehl
    </th>
    
    <th>
      Funktion
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /workspace <folder>
      </code>
    </td>
    
    <td>
      Registriert einen bestehenden Ordner als Workspace des Chats (erfordert Freigabe in der Konfiguration)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /help
      </code>
    </td>
    
    <td>
      Listet alle verfügbaren Befehle auf
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /time
      </code>
    </td>
    
    <td>
      Zeigt die aktuelle Serverzeit an
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /new
      </code>
    </td>
    
    <td>
      Startet eine frische, saubere Sitzung
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /clear
      </code>
    </td>
    
    <td>
      Löscht den bisherigen Gesprächsverlauf
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /status
      </code>
    </td>
    
    <td>
      Gibt den aktuellen Betriebszustand der Bridge aus
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /stats
      </code>
    </td>
    
    <td>
      Liefert Chat-Zähler und detaillierte Statuszeilen aller Bridges (inklusive Buzz)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /commands
      </code>
    </td>
    
    <td>
      Detaillierte Übersicht aller Befehlsbeschreibungen
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        @path/to/file
      </code>
    </td>
    
    <td>
      Verhält sich wie @-Dateierwähnungen im Web: Das Modell liest die Datei relativ zum Chat-Workspace; <code>
        @
      </code>
      
      , <code>
        @präfix
      </code>
      
       oder <code>
        /files <präfix>
      </code>
      
       antwortet mit passenden Dateien/Ordnern
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /model
      </code>
    </td>
    
    <td>
      <code>
        [provider model effort]
      </code>
      
       — validiert gegen den aktiven Modellkatalog; <code>
        /model
      </code>
      
       listet Optionen, <code>
        /model reset
      </code>
      
       setzt auf Standard zurück
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /effort
      </code>
    </td>
    
    <td>
      <code>
        <id>
      </code>
      
       passt gezielt die Reasoning-Anstrengung an; <code>
        /effort reset
      </code>
      
       setzt den Standardwert wieder ein
    </td>
  </tr>
</tbody>
</table>

### Sicherheitsaspekte im Überblick

- Der private Schlüssel **nsec** liegt geschützt in `~/.dsh/gateway.json` (Rechte 0600, atomare Schreibvorgänge) — er wird niemals über `/gateway/list` exponiert oder in Protokollen ausgegeben.
- Jedes eingehende Event wird **kryptografisch signaturgeprüft** (`verifyEvent`), dedupliziert, auf Selbstaussendung gefiltert und durch Erwähnungsprüfungen geleitet, bevor es den Agenten erreicht.
- **Die Workspace-Registrierung ist strikt konfigurationsgesteuert** (`allowWorkspace: false` als Standard), um unbefugten Zugriff auf lokale Systemverzeichnisse abzusichern.

## Fazit: Dezentrale KI-Zusammenarbeit in Buzz

Die größte Herausforderung bei der Integration von Buzz in `dsh-message-gateway` lag in der konsequenten Erfüllung des Nostr-Protokollvertrags. Da die Plugin-Basis bereits eine ausgereifte Sitzungsverwaltung und Befehlsweiterleitung bot, fügte sich die Bridge nahtlos ein, sobald Event-Verarbeitung und In-Place-Streaming etabliert waren.

## Referenzen:

- [dsh-message-gateway architecture guide](https://github.com/a792883583/dsh-message-gateway/blob/main/docs/architecture.md) — Architekturleitfaden, Erweiterungsanleitung und Sicherheitshinweise
- [nostr-tools](https://github.com/nbd-wtf/nostr-tools) — Unter der Haube verwendete Nostr-Bibliothek
- [deer-flow IM channel connections](https://github.com/bytedance/deer-flow/blob/main/backend/docs/IM_CHANNEL_CONNECTIONS.md) — Referenzarchitektur für Instant-Messaging-Kanäle