Connecter DeepSeek Harness à Buzz: La passerelle Nostr

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.

Guide prérequis

Auto-héberger Buzz de Block: Espace collaboratif d'agents IA

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.

12 MIN DE LECTURE

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 :

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

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 :

• 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) :

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.

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 :

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

# Start DSH web
dsh web

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

3. Cliquez sur "Buzz" dans le menu de gauche :

4. Cliquez sur "Generate keypair" pour générer une paire de clés Nostr. Conservez précieusement la clé publique npub.
5. Renseignez la Relay URL ainsi que les Channels (la liste autorisée des UUIDs de canaux à écouter).
6. 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 :

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) :

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

Guide CLI

Comment installer et utiliser buzz-cli

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.

5 MIN DE LECTURE

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

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

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 :

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

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

Après redémarrage :

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.

Commandes supportées dans Buzz

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

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 — guide d'architecture, recettes d'extension et sécurité
• nostr-tools — bibliothèque Nostr exploitée sous le capot
• deer-flow IM channel connections — modèles de référence pour les connexions de messagerie instantanée