---
title: "Conectar DeepSeek Harness ao Buzz: O Gateway de Nostr"
description: "Integre o DeepSeek Harness ao Block Buzz com uma ponte Nostr. Configure auth NIP-42, streaming de mensagens in-place e espaços de trabalho de agentes de IA."
canonical_url: "https://techvoyage.dev/pt/article/bringing-buzz-to-deepseek-harness"
last_updated: "2026-10-20T09:53:42.809Z"
---

![Visão geral do gateway de mensagens DeepSeek Harness conectado a um canal do Block Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-nostr-gateway-overview.webp)

O plugin do DeepSeek Harness (DSH), **dsh-message-gateway**, estende o assistente DeepSeek Harness a múltiplas plataformas de mensagens, como Discord, Telegram e WeChat. O repositório do plugin foi bifurcado e estendido para adicionar a plataforma **Como auto-hospedar o Buzz do Block: Espaço para agentes de IA** à lista. O repositório bifurcado está disponível no GitHub em [https://github.com/Tech-Voyage-Dev/dsh-message-gateway](https://github.com/Tech-Voyage-Dev/dsh-message-gateway).

<article-card description="Aprenda a auto-hospedar o relay Buzz da Block em um VPS Linux com Cloudflare. Crie um espaço de trabalho seguro baseado em Nostr para humanos e agentes IA." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/PT-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Um cartão tecnológico premium de 16:9 com detalhes em azul profundo e laranja ilustrando como auto-hospedar o relay Buzz do Block em um VPS Ubuntu, apresentando um painel glassmorphic limpo com tipografia centrada." label="Guia de pré-requisitos" min-read="12" title="Como auto-hospedar o Buzz do Block: Espaço para agentes de IA" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues">



</article-card>

O assistente DSH ingressa em um relay do Buzz como membro, recebe mensagens diretas (DMs) e mensagens de canal onde é @mencionado, e responde pelo mesmo pipeline de agentes por chat utilizado na interface Web.

## Arquitetura do plugin dsh-message-gateway

A arquitetura do plugin **dsh-message-gateway** é dividida em duas camadas principais:

- **Host** (Node): `gateway-store` (credenciais em `~/.dsh/gateway.json`), `platforms.ts` (definições de plataformas e testes de conexão), `routes.ts` (endpoints `/gateway/*`) e `bridge-manager.ts` (as pontes residentes: sessões de agentes independentes por chat e respostas em streaming).
- **Cliente** (navegador): a página "**Message platforms**" na barra lateral, onde você salva credenciais, testa conexões e monitora o status do serviço.

Adicionar uma nova plataforma envolve as seguintes etapas:

1. **Uma classe de ponte (bridge)**: implementando os métodos `start/stop/status` e o callback `onText(text, frame)`, espelhando o padrão de `wecom-bridge.ts`.
2. **Integração no bridge-manager**: reaproveitar o pipeline existente por conversa (`ensureAgentForKey` + `pendingMap`) e conectar o coletor de respostas da plataforma.
3. **Persistência e rotas**: em `/gateway/save` e `/gateway/delete`: **salvar credenciais inicia a ponte, excluí-las a encerra** — complementado por uma flag `autoStartXxx` para que o `dsh web` reconecte automaticamente no boot.

## Implementação da ponte do Buzz: Protocolo Nostr e ciclo de vida de eventos

O **DeepSeek Harness** foi utilizado para implementar a ponte do Buzz. A implementação atende rigorosamente às seguintes especificações do protocolo Nostr:

<table>
<thead>
  <tr>
    <th>
      <strong>
        Transporte
      </strong>
    </th>
    
    <th>
      Um único WebSocket autenticado via NIP-42; padrão <code>
        ws://localhost:3000
      </code>
      
      ; <code>
        http(s)://
      </code>
      
       é normalizado para <code>
        ws(s)://
      </code>
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Autenticação
      </strong>
    </td>
    
    <td>
      Evento AUTH <code>
        kind 22242
      </code>
      
      , tags <code>
        [["relay", url], ["challenge", challenge]]
      </code>
      
      , conteúdo vazio, assinado com a chave do agente
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Inscrições
      </strong>
    </td>
    
    <td>
      <strong>
        Por canal
      </strong>
      
      : <code>
        REQ {"kinds":[9], "#h":[<uuid>]}
      </code>
      
       — um REQ por canal. Um REQ global <code>
        kinds:[9]
      </code>
      
       recebe EOSE mas nunca distribui eventos; filtro <code>
        #h
      </code>
      
       multivalorado <strong>
        não
      </strong>
      
       funciona
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Descoberta
      </strong>
    </td>
    
    <td>
      <code>
        REQ {kinds:[39000]}
      </code>
      
       histórico para metadados de canal (<code>
        type == "dm"
      </code>
      
       marca canal de mensagem direta)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Associação
      </strong>
    </td>
    
    <td>
      <code>
        REQ {kinds:[44100,44101], "#p":[nossa pubkey], since: now-60s}
      </code>
      
       ao vivo — 44100 = adição, 44101 = remoção, com <code>
        p
      </code>
      
      +<code>
        h
      </code>
      
      ; atualiza inscrições <strong>
        sem reconectar
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Eventos de chat
      </strong>
    </td>
    
    <td>
      <code>
        kind 9
      </code>
      
       com tags <code>
        ["h", canal]
      </code>
      
      , opcional <code>
        ["e", replyTo]
      </code>
      
      , <code>
        ["p", menção]
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Edições in-place
      </strong>
    </td>
    
    <td>
      <code>
        kind 40003
      </code>
      
       com <code>
        h
      </code>
      
       + <code>
        e
      </code>
      
      →alvo; substituição de conteúdo; limite do relay de 64 KB → manter payloads ≤ 60.000 B; respostas longas são fragmentadas — chunk 0 na edição, o restante adicionado como mensagens <code>
        kind 9
      </code>
      
       encadeadas (<code>
        e
      </code>
      
      →raiz)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Quadros CLOSED
      </strong>
    </td>
    
    <td>
      <code>
        auth-required
      </code>
      
       antes de AUTH é normal durante o bootstrap (completar AUTH e reabrir inscrições); após AUTH → retentativa delimitada (3 tentativas, backoff 0/1/2 s); reconexão reconstrói tudo
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Limites do relay
      </strong>
    </td>
    
    <td>
      ≤ 2000 eventos históricos por inscrição, ordenados do mais recente para o mais antigo, mesmo utilizando <code>
        since
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Filtro de menções
      </strong>
    </td>
    
    <td>
      Processa <code>
        kind 9
      </code>
      
       de entrada apenas quando: (a) tag <code>
        p
      </code>
      
       inclui nossa pubkey, (b) o canal é DM, ou (c) a raiz <code>
        e
      </code>
      
       pertence ao nosso agente. Ignora a própria pubkey (anti-loop)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Menções de saída
      </strong>
    </td>
    
    <td>
      Texto publicado sem alterações — o relay não valida tokens <code>
        @
      </code>
      
      ; tags <code>
        p
      </code>
      
       incluem o autor de origem mais até 7 outras pubkeys mencionadas (máx. 8)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Mensagens diretas
      </strong>
    </td>
    
    <td>
      Canais de texto simples no escopo do relay (metadados <code>
        type: "dm"
      </code>
      
      ) — sem criptografia NIP-04/44 nesta ponte
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Anexos (entrada)
      </strong>
    </td>
    
    <td>
      NIP-92 <code>
        imeta
      </code>
      
       (<code>
        url
      </code>
      
      , <code>
        sha256
      </code>
      
      , <code>
        m
      </code>
      
      ) → download http(s), verificação de SHA-256, limite de 20 MB, máx. 4 por mensagem; imagens de saída não suportadas
    </td>
  </tr>
</tbody>
</table>

O diagrama abaixo ilustra o fluxo de inicialização (bootstrap) da ponte do Buzz:

![Diagrama de sequência ilustrando o processo de bootstrap e autenticação NIP-42 da ponte Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-bootstrap.webp)### Streaming em tempo real via edições in-place do Nostr (Kind 40003)

Como o Nostr não possui indicador nativo de digitação e seus eventos são estritamente cumulativos (append-only), a ponte do Buzz **simula streaming por meio de edições in-place**:

![Diagrama do fluxo de edição in-place simulando respostas em streaming com eventos kind 40003](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-reply.webp)- *A ponte do Buzz publica primeiro um evento placeholder kind 9, depois o reescreve progressivamente com edições in-place kind 40003 com taxa controlada e grava a edição final quando o agente conclui a resposta. Esse mecanismo segue o mesmo padrão consagrado das pontes do Telegram e Discord.*

### Conexão de workspaces do DeepSeek Harness via comandos de chat

O recurso de "Workspaces" na interface Web do DSH é gerenciado pelo serviço `workspaceRegistry` (`@deepseek-ai/dsh-workspace`):

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

A ponte do Buzz disponibiliza o comando de chat `/workspace <pasta>`, que registra uma pasta existente no DSH. Qualquer nova sessão criada pelo gateway é anexada a essa pasta e exibida na interface Web.

![Arquitetura do registro de espaços de trabalho do DeepSeek Harness a partir de comandos de chat](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace.webp)Três regras de projeto essenciais:

- **Mudar de pasta = nova sessão.** O valor de `cwd` é gravado no cabeçalho da sessão no momento da criação e não pode ser alterado posteriormente.
- **A pasta deve existir previamente.** O método `create` rejeita caminhos inexistentes.
- **Comando com sensibilidade de segurança.** Toda sessão opera sob uma política de **auto-aprovação**, concedendo acesso aos arquivos da pasta de destino.

## Guia passo a passo de instalação e configuração

1. Execute os seguintes comandos no terminal:

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

# Start DSH web
dsh web
```

1. Assim que a interface Web do DSH abrir no navegador, clique no ícone "**Message platforms**":

![Barra lateral da interface Web do DeepSeek Harness destacando o menu Message platforms](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-message-platforms-sidebar-icon.webp)

1. Selecione "**Buzz**" no painel esquerdo:

![Painel de configurações da ponte Buzz no gateway de mensagens do DeepSeek Harness](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-message-gateway-buzz-config-panel.webp)

1. Clique em "**Generate keypair**" para gerar o par de chaves Nostr. Guarde a chave pública `npub` em local seguro.
2. Preencha a **Relay URL** e os **Channels** (a lista autorizada de UUIDs dos canais que serão assinados).
3. Clique no botão "**Save**".

Ao salvar o formulário, as credenciais são armazenadas e **a ponte é iniciada**. A chave privada `nsec` é protegida como segredo e gravada exclusivamente em `~/.dsh/gateway.json`.

### Registro do par de chaves do agente no relay Nostr do Buzz

**Adicione o assistente DSH ao relay como membro.** Utilize a chave `npub` gerada na etapa anterior:

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

**Adicione o assistente a um canal específico.** Apenas registrar o membro no relay não o torna visível nem pesquisável nos canais. Para adicioná-lo via `buzz-cli`, lembre-se de que o parâmetro `--pubkey` deve estar no formato **HEX**, e não npub (o comando `buzz-admin add-member` exibe a chave HEX correspondente):

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

<article-card description="Instruções passo a passo para instalar e configurar o buzz-cli para gerir canais Nostr, chaves de membros e permissões de agentes de IA." image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/PT-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="Um cartão tecnológico premium de 16:9 com detalhes em azul profundo e laranja ilustrando como auto-hospedar o relay Buzz do Block em um VPS Ubuntu, apresentando um painel glassmorphic limpo com tipografia centrada." label="Guia da CLI" min-read="5" title="Como instalar e usar o buzz-cli" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues#install-buzz-cli">



</article-card>

Atualize o perfil do assistente no relay Nostr definindo um nome amigável com o `buzz-cli`:

![Atualização do nome do assistente DeepSeek Harness no relay Nostr usando buzz-cli](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-assistant-buzz-cli-profile-update.webp)

Envie uma saudação **Wave** (a saudação padrão de DM do Buzz) para o assistente. O retorno confirma a operação:

![Teste de conexão enviando uma saudação Wave por DM para o assistente DeepSeek Harness no Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-dm-wave-greeting-reply.webp)

*Enviando uma Wave por mensagem direta para o assistente DSH — a ponte está ativa.*

### Habilitando o acesso a pastas locais com `/workspace`

Como a configuração `allowWorkspace` vem desativada (`false`) por padrão, o comando `/workspace` será inicialmente recusado:

![Notificação de erro mostrando a rejeição do comando workspace com allowWorkspace desativado](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-rejected-error.webp)

Ative a funcionalidade em `~/.dsh/profiles/web/cordis.patch.yml` e reinicie o `dsh web`:

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

Após reiniciar:

![Mensagem de confirmação de sucesso após executar o comando de registro de workspace no Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-success-confirmation.webp)

Dica importante: o sistema presume que a pasta do workspace (`TechVoyage` nas capturas) esteja no diretório padrão do usuário. Caso contrário, informe o caminho absoluto. Qualquer nova sessão criada sob este workspace pelo Buzz também aparecerá na interface Web do DeepSeek Harness.

![Interface Web do DeepSeek Harness exibindo a sessão de workspace sincronizada do Buzz](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-synced-workspace-session.webp)

### Comandos disponíveis no Buzz

Todos os comandos disponíveis nas demais plataformas suportadas funcionam normalmente no Buzz:

<table>
<thead>
  <tr>
    <th>
      Comando
    </th>
    
    <th>
      O que faz
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /workspace <folder>
      </code>
    </td>
    
    <td>
      Registra uma pasta existente como o workspace da conversa (requer habilitação nas configurações)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /help
      </code>
    </td>
    
    <td>
      Lista os comandos disponíveis
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /time
      </code>
    </td>
    
    <td>
      Mostra a hora atual do sistema
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /new
      </code>
    </td>
    
    <td>
      Inicia uma nova sessão de conversa limpa
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /clear
      </code>
    </td>
    
    <td>
      Limpa o histórico da conversa atual
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /status
      </code>
    </td>
    
    <td>
      Exibe o status operacional da ponte
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /stats
      </code>
    </td>
    
    <td>
      Mostra a contagem de conversas e linhas de status por ponte (todas as plataformas, incluindo Buzz)
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /commands
      </code>
    </td>
    
    <td>
      Lista descritiva com todos os comandos
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        @path/to/file
      </code>
    </td>
    
    <td>
      Funciona exatamente como menções de arquivos na Web: o modelo lê o arquivo relativo ao workspace; <code>
        @
      </code>
      
      , <code>
        @prefixo
      </code>
      
       ou <code>
        /files <prefixo>
      </code>
      
       retornam arquivos e pastas correspondentes
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /model
      </code>
    </td>
    
    <td>
      <code>
        [provider model effort]
      </code>
      
       — valida contra o catálogo ativo de LLMs; <code>
        /model
      </code>
      
       lista as opções disponíveis e <code>
        /model reset
      </code>
      
       restaura os padrões
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /effort
      </code>
    </td>
    
    <td>
      <code>
        <id>
      </code>
      
       ajusta apenas o esforço de raciocínio do modelo; <code>
        /effort reset
      </code>
      
       restaura o valor padrão
    </td>
  </tr>
</tbody>
</table>

### Resumo das medidas de segurança

- A chave privada **nsec** reside unicamente em `~/.dsh/gateway.json` (permissões 0600, gravação atômica) — nunca sendo exposta em `/gateway/list` nem em logs.
- Todo evento de entrada passa por **validação de assinatura criptográfica** (`verifyEvent`), desduplicação, filtro de mensagens próprias e controle de menções antes de alcançar o agente.
- **O registro de workspaces é bloqueado por configuração** (`allowWorkspace: false` por padrão), garantindo controle total contra acesso indevido aos arquivos da máquina.

## Conclusão: Colaboração com agentes de IA descentralizados no Buzz

O maior desafio ao incorporar o Buzz ao `dsh-message-gateway` esteve na conformidade com o protocolo Nostr. Como a base do plugin já contava com uma sólida arquitetura de sessões por conversa e despacho de comandos, a integração correu de maneira muito fluida assim que a manipulação de eventos e o streaming foram resolvidos.

## Referências:

- [dsh-message-gateway architecture guide](https://github.com/a792883583/dsh-message-gateway/blob/main/docs/architecture.md) — guia de arquitetura, receitas de extensão e notas de segurança
- [nostr-tools](https://github.com/nbd-wtf/nostr-tools) — biblioteca Nostr utilizada sob o capô
- [deer-flow IM channel connections](https://github.com/bytedance/deer-flow/blob/main/backend/docs/IM_CHANNEL_CONNECTIONS.md) — referências para arquiteturas de conexão em canais de mensageria