---
title: "Connecter DeepSeek Harness à Buzz: La passerelle Nostr"
description: "Intégrez DeepSeek Harness à Block Buzz via une passerelle Nostr. Configurez auth NIP-42, flux de messages in situ et espaces de travail d'agents IA par canal."
canonical_url: "https://techvoyage.dev/fr/article/bringing-buzz-to-deepseek-harness"
last_updated: "2026-10-20T09:53:46.637Z"
---

![Vue d'ensemble de la passerelle de messagerie DeepSeek Harness connectée à un canal Block Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-nostr-gateway-overview.webp)

Le plugin pour DeepSeek Harness (DSH), **dsh-message-gateway**, étend l'assistant DeepSeek Harness à de multiples plateformes de messagerie telles que Discord, Telegram et WeChat. Le dépôt du plugin a été forké et enrichi pour ajouter la plateforme **Auto-héberger Buzz de Block: Espace collaboratif d'agents IA** à la liste. Le dépôt forké est disponible sur GitHub à l'adresse [https://github.com/Tech-Voyage-Dev/dsh-message-gateway](https://github.com/Tech-Voyage-Dev/dsh-message-gateway).

<article-card description="Découvrez comment auto-héberger le relay Buzz sur un VPS Linux derrière Cloudflare. Créez un espace de travail Nostr où humains et agents IA collaborent." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/FR-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Une carte technologique premium de 16:9 avec des touches de bleu foncé et d'orange illustrant comment auto-héberger le relais Buzz de Block sur un VPS Ubuntu, avec un panneau de style glassmorphic épuré avec typographie centrée." label="Guide prérequis" min-read="12" title="Auto-héberger Buzz de Block: Espace collaboratif d'agents IA" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues">



</article-card>

L'assistant DSH rejoint un relais Buzz en tant que membre à part entière, reçoit les messages directs (DM) ainsi que les messages de canal où il est @mentionné, et répond à travers le même pipeline d'agents par conversation qu'utilise l'interface Web.

## Architecture du plugin dsh-message-gateway

L'architecture du plugin **dsh-message-gateway** s'articule autour de deux volets complémentaires :

- **Hôte** (Node) : `gateway-store` (gestion des identifiants dans `~/.dsh/gateway.json`), `platforms.ts` (définitions des plateformes et tests de connexion), `routes.ts` (endpoints `/gateway/*`) et `bridge-manager.ts` (les passerelles résidentes : sessions d'agents indépendantes par canal et streaming des réponses).
- **Client** (navigateur) : la page "**Message platforms**" dans la barre latérale, permettant de renseigner les accès, tester la connectivité et surveiller l'état en direct.

L'intégration d'une nouvelle plateforme nécessite les étapes suivantes :

1. **Une classe de passerelle (bridge)** : proposant les méthodes `start/stop/status` et un callback `onText(text, frame)`, à l'image de `wecom-bridge.ts`.
2. **Câblage dans bridge-manager** : réutilisation du pipeline par conversation existant (`ensureAgentForKey` + `pendingMap`) en branchant le collecteur de réponses de la plateforme.
3. **Persistance et routage** : dans `/gateway/save` et `/gateway/delete` : **enregistrer les identifiants démarre la passerelle, les supprimer l'arrête** — complété d'un drapeau `autoStartXxx` assurant la reconnexion automatique au démarrage de `dsh web`.

## Implémentation de la passerelle Buzz : Protocole Nostr et cycle de vie des événements

**DeepSeek Harness** a été utilisé pour développer la passerelle Buzz. L'implémentation respecte scrupuleusement les spécifications du protocole Nostr :

<table>
<thead>
  <tr>
    <th>
      <strong>
        Transport
      </strong>
    </th>
    
    <th>
      Un unique WebSocket authentifié via NIP-42 ; par défaut <code>
        ws://localhost:3000
      </code>
      
       ; <code>
        http(s)://
      </code>
      
       est normalisé en <code>
        ws(s)://
      </code>
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Authentification
      </strong>
    </td>
    
    <td>
      Événement AUTH <code>
        kind 22242
      </code>
      
      , tags <code>
        [["relay", url], ["challenge", challenge]]
      </code>
      
      , contenu vide, signé avec la clé privée de l'agent
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Abonnements
      </strong>
    </td>
    
    <td>
      <strong>
        Par canal
      </strong>
      
       : <code>
        REQ {"kinds":[9], "#h":[<uuid>]}
      </code>
      
       — un REQ par canal. Un REQ global <code>
        kinds:[9]
      </code>
      
       reçoit EOSE sans jamais distribuer d'événements ; le filtre <code>
        #h
      </code>
      
       multivalué <strong>
        échoue
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Découverte
      </strong>
    </td>
    
    <td>
      <code>
        REQ {kinds:[39000]}
      </code>
      
       historique pour récupérer les métadonnées (<code>
        type == "dm"
      </code>
      
       signale un canal de messagerie directe)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Adhésion aux canaux
      </strong>
    </td>
    
    <td>
      <code>
        REQ {kinds:[44100,44101], "#p":[notre pubkey], since: now-60s}
      </code>
      
       en direct — 44100 = ajout, 44101 = retrait, avec <code>
        p
      </code>
      
      +<code>
        h
      </code>
      
       ; met à jour les abonnements <strong>
        sans reconnexion
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Événements de chat
      </strong>
    </td>
    
    <td>
      <code>
        kind 9
      </code>
      
       avec tags <code>
        ["h", canal]
      </code>
      
      , et facultativement <code>
        ["e", replyTo]
      </code>
      
      , <code>
        ["p", mention]
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Éditions sur place
      </strong>
    </td>
    
    <td>
      <code>
        kind 40003
      </code>
      
       avec <code>
        h
      </code>
      
       + <code>
        e
      </code>
      
      →cible ; remplacement du contenu ; plafond relais de 64 Ko → charge utile ≤ 60 000 octets ; découpage des longues réponses — le tronçon 0 remplace l'édition, les suivants s'ajoutent en <code>
        kind 9
      </code>
      
       dans le fil (<code>
        e
      </code>
      
      →racine)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Trames CLOSED
      </strong>
    </td>
    
    <td>
      <code>
        auth-required
      </code>
      
       avant AUTH est normal au bootstrap (terminer AUTH, rouvrir subs) ; post-AUTH → réabonnement borné (3 tentatives, temporisation 0/1/2 s) ; la reconnexion réinitialise tout
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Limites du relais
      </strong>
    </td>
    
    <td>
      ≤ 2000 événements historiques par abonnement, triés du plus récent au plus ancien, même avec le filtre <code>
        since
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Filtrage des mentions
      </strong>
    </td>
    
    <td>
      Traite les <code>
        kind 9
      </code>
      
       entrants uniquement si : (a) le tag <code>
        p
      </code>
      
       inclut notre pubkey, (b) le canal est un DM, ou (c) la racine <code>
        e
      </code>
      
       provient de notre agent. Ignore notre pubkey (anti-boucle)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Mentions sortantes
      </strong>
    </td>
    
    <td>
      Texte publié tel quel — le relais ne valide pas les tokens <code>
        @
      </code>
      
       ; les tags <code>
        p
      </code>
      
       intègrent l'auteur source et jusqu'à 7 autres pubkeys mentionnées (max 8)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Messages directs
      </strong>
    </td>
    
    <td>
      Canaux en texte brut confinés au relais (métadonnées <code>
        type: "dm"
      </code>
      
      ) — sans chiffrement NIP-04/44 dans cette passerelle
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Pièces jointes
      </strong>
    </td>
    
    <td>
      NIP-92 <code>
        imeta
      </code>
      
       (<code>
        url
      </code>
      
      , <code>
        sha256
      </code>
      
      , <code>
        m
      </code>
      
      ) → téléchargement http(s), contrôle SHA-256, limite de 20 Mo, max 4 par message ; images sortantes non prises en charge
    </td>
  </tr>
</tbody>
</table>

Le schéma ci-dessous détaille le processus d'initialisation (bootstrap) de la passerelle Buzz :

![Diagramme de séquence illustrant l'initialisation et l'authentification NIP-42 de la passerelle Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-bootstrap.webp)### Streaming en temps réel via les éditions sur place Nostr (Kind 40003)

Nostr ne disposant pas d'indicateur de frappe natif et ses événements étant strictement append-only, la passerelle Buzz **simule un affichage fluide en direct grâce aux réécritures sur place** :

![Diagramme du flux d'édition sur place simulant les réponses en direct avec les événements kind 40003](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-reply.webp)- *La passerelle Buzz émet d'abord un événement temporaire kind 9, puis le réécrit progressivement avec des éditions in situ kind 40003 cadencées, avant de sceller la version finale dès que l'agent termine sa génération. Ce mécanisme reprend le principe éprouvé des passerelles Telegram et Discord.*

### Connexion des espaces de travail DeepSeek Harness via commandes de chat

Dans l'interface Web de DSH, la gestion des espaces de travail s'appuie sur le service `workspaceRegistry` (`@deepseek-ai/dsh-workspace`) :

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

La passerelle Buzz met à disposition la commande `/workspace <dossier>`, qui associe un répertoire existant dans DSH. Toute nouvelle session initiée via la passerelle s'y rattache et devient consultable dans l'interface Web.

![Architecture de l'enregistrement des espaces de travail DeepSeek Harness via les commandes de chat](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace.webp)Trois règles d'architecture fondamentales :

- **Changer de dossier = créer une nouvelle session.** La variable `cwd` est inscrite dans l'en-tête de la session lors de sa création et demeure immuable.
- **Le dossier doit impérativement exister.** L'appel `create` rejette tout chemin inexistant.
- **Commande sensible du point de vue de la sécurité.** Les sessions bénéficient d'une politique **auto-approve**, conférant un accès direct aux fichiers du dossier ciblé.

## Guide pas à pas d'installation et de configuration

1. Exécutez les commandes suivantes dans votre terminal :

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

# Start DSH web
dsh web
```

1. Dès que l'interface Web de DSH est accessible dans votre navigateur, cliquez sur l'icône "**Message platforms**" :

![Barre latérale de l'interface Web DeepSeek Harness mettant en évidence le menu Message platforms](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-message-platforms-sidebar-icon.webp)

1. Cliquez sur "**Buzz**" dans le menu de gauche :

![Panneau des paramètres de configuration de la passerelle Buzz dans DeepSeek Harness](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-message-gateway-buzz-config-panel.webp)

1. Cliquez sur "**Generate keypair**" pour générer une paire de clés Nostr. Conservez précieusement la clé publique `npub`.
2. Renseignez la **Relay URL** ainsi que les **Channels** (la liste autorisée des UUIDs de canaux à écouter).
3. Cliquez sur le bouton "**Save**".

L'enregistrement du formulaire stocke les paramètres et **démarre la passerelle**. La clé privée `nsec` est traitée comme un secret sensible, confinée dans `~/.dsh/gateway.json`.

### Enregistrement de la clé de l'agent sur le relais Nostr de Buzz

**Ajoutez l'assistant DSH au relais en tant que membre.** Indiquez la clé publique `npub` générée précédemment :

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

**Attribuez l'assistant à un canal donné.** L'inscription sur le relais ne rend pas automatiquement le membre visible dans les canaux. Pour l'ajouter avec `buzz-cli`, veillez à renseigner le paramètre `--pubkey` en format **HEX** et non npub (la commande `buzz-admin add-member` affiche la clé HEX correspondante) :

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

<article-card description="Instructions détaillées pour installer et configurer buzz-cli afin de gérer les canaux Nostr, les clés des membres et les autorisations des agents IA." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/FR-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Une carte technologique premium de 16:9 avec des touches de bleu foncé et d'orange illustrant comment auto-héberger le relais Buzz de Block sur un VPS Ubuntu, avec un panneau de style glassmorphic épuré avec typographie centrée." label="Guide CLI" min-read="5" title="Comment installer et utiliser buzz-cli" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues#install-buzz-cli">



</article-card>

Personnalisez le profil de l'assistant sur le relais Nostr avec un nom évocateur via `buzz-cli` :

![Mise à jour du nom de l'assistant DeepSeek Harness sur le relais Nostr avec buzz-cli](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-assistant-buzz-cli-profile-update.webp)

Transmettez un **Wave** (la salutation de bienvenue de Buzz en message privé) à l'assistant. L'écho confirme la bonne liaison :

![Test de connexion en envoyant un message Wave en DM à l'assistant DeepSeek Harness dans Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-dm-wave-greeting-reply.webp)

*Envoi d'un Wave en message direct à l'assistant DSH — la passerelle répond immédiatement.*

### Activation de l'accès aux dossiers locaux via `/workspace`

Le paramètre `allowWorkspace` étant désactivé (`false`) par défaut, la commande `/workspace` est initialement rejetée :

![Notification d'erreur indiquant le rejet de la commande workspace lorsque allowWorkspace est inactif](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-rejected-error.webp)

Activez-le dans `~/.dsh/profiles/web/cordis.patch.yml`, puis relancez `dsh web` :

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

Après redémarrage :

![Confirmation d'exécution réussie de la commande d'enregistrement de l'espace de travail dans Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-success-confirmation.webp)

Remarque essentielle : le système considère par défaut que le dossier de travail (`TechVoyage` sur nos captures) se trouve dans le répertoire utilisateur courant. Dans le cas contraire, spécifiez un chemin absolu. Toute session créée dans cet espace depuis Buzz s'affiche également dans l'interface Web de DeepSeek Harness.

![Interface Web DeepSeek Harness affichant la session d'espace de travail synchronisée depuis Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-synced-workspace-session.webp)

### Commandes supportées dans Buzz

L'ensemble des commandes disponibles sur les autres passerelles fonctionne sur Buzz :

<table>
<thead>
  <tr>
    <th>
      Commande
    </th>
    
    <th>
      Rôle
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /workspace <folder>
      </code>
    </td>
    
    <td>
      Associe un dossier existant comme espace de travail pour la discussion (soumis à activation de config)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /help
      </code>
    </td>
    
    <td>
      Affiche la liste des commandes disponibles
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /time
      </code>
    </td>
    
    <td>
      Donne l'heure actuelle du serveur
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /new
      </code>
    </td>
    
    <td>
      Démarre une session de discussion vierge
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /clear
      </code>
    </td>
    
    <td>
      Réinitialise la conversation en cours
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /status
      </code>
    </td>
    
    <td>
      Retourne le statut opérationnel de la passerelle
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /stats
      </code>
    </td>
    
    <td>
      Détaille le volume de discussions et le statut par passerelle (toutes plateformes confondues, dont Buzz)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /commands
      </code>
    </td>
    
    <td>
      Inventaire exhaustif des descripteurs de commandes
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        @path/to/file
      </code>
    </td>
    
    <td>
      Fonctionne à l'identique des mentions de fichiers Web : lecture contextuelle relative au workspace ; <code>
        @
      </code>
      
      , <code>
        @prefixe
      </code>
      
       ou <code>
        /files <prefixe>
      </code>
      
       listent les fichiers et répertoires correspondants
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /model
      </code>
    </td>
    
    <td>
      <code>
        [provider model effort]
      </code>
      
       — validé face au catalogue LLM actif ; <code>
        /model
      </code>
      
       seul liste les choix, <code>
        /model reset
      </code>
      
       rétablit la configuration par défaut
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /effort
      </code>
    </td>
    
    <td>
      <code>
        <id>
      </code>
      
       ajuste le niveau d'effort de raisonnement ; <code>
        /effort reset
      </code>
      
       rétablit la valeur par défaut
    </td>
  </tr>
</tbody>
</table>

### Synthèse sur la sécurité

- La clé privée **nsec** demeure confinée dans `~/.dsh/gateway.json` (droits 0600, écriture atomique) — jamais exposée via `/gateway/list` ni dans les journaux d'exécution.
- Chaque événement reçu subit une **validation de signature cryptographique** (`verifyEvent`), une déduplication, un filtrage d'auto-émission et un contrôle de mention préalable.
- **L'enregistrement des workspaces requiert une validation de configuration expresse** (`allowWorkspace: false` par défaut), évitant toute ouverture imprévue du système de fichiers local.

## Conclusion : L'avenir de la collaboration IA décentralisée avec Buzz

La complexité principale de l'intégration de Buzz dans `dsh-message-gateway` résidait dans l'implémentation fidèle des spécifications Nostr. L'architecture modulaire du plugin fournissait déjà un socle solide pour l'isolation des sessions et la gestion des commandes, rendant le déploiement fluide une fois la mécanique d'événements et le streaming synchronisés.

## Références :

- [dsh-message-gateway architecture guide](https://github.com/a792883583/dsh-message-gateway/blob/main/docs/architecture.md) — guide d'architecture, recettes d'extension et sécurité
- [nostr-tools](https://github.com/nbd-wtf/nostr-tools) — bibliothèque Nostr exploitée sous le capot
- [deer-flow IM channel connections](https://github.com/bytedance/deer-flow/blob/main/backend/docs/IM_CHANNEL_CONNECTIONS.md) — modèles de référence pour les connexions de messagerie instantanée