Chinesezjc/dsh-interconnect
282Last commit Aug 14, 2026
dsh-interconnect DSH plugin
dsh-interconnect enables a DSH instance to send messages, probe liveness, and push events bidirectionally to other instances—on the same machine or across machines. It provides an HTTP/WebSocket host service (`interconnect`) and model-visible tools (`tool-interconnect`) for agent-driven cross-instance communication.
How to install the dsh-interconnect DSH plugin
dsh plugin --profile <name> add dsh-interconnectThis source command needs manual review. Copying does not run it.
dsh-interconnect DSH plugin data source
dsh-interconnect DSH plugin snapshot date: Aug 16, 2026
discovered
What the dsh-interconnect DSH plugin can do
- Send messages and ping liveness via HTTP endpoints (`/interconnect/send`, `/interconnect/ping`)
- Real-time bidirectional event streaming over WebSocket at `/interconnect/link` with heartbeat and exponential backoff reconnection
- Shared secret authentication (bearer token `DSH_INTERCONNECT_TOKEN`) with timing-safe comparison and fail-closed behavior
- Inbound events emitted as `interconnect/event` to the local instance
- Model-accessible tools: `interconnect_send` (deliver message to a remote session) and `interconnect_ping` (probe remote instance identity and health)
Where the dsh-interconnect DSH plugin fits
- Deliver messages from one DSH instance to another, enabling cross-instance agent coordination
- Probe whether a remote instance is alive and verify its identity before sending sensitive data
- Push real-time events (e.g., state changes, alerts) between instances via WebSocket link
- Let an agent on one instance send a message back to a session on another instance using the `interconnect_send` tool
Who the dsh-interconnect DSH plugin is for
- DSH users who need to connect multiple DSH instances for distributed agent workflows
- Developers building multi-instance or multi-machine agent systems that require reliable cross-instance messaging and event notification
dsh-interconnect DSH plugin limitations
- Requires both instances to set the same `DSH_INTERCONNECT_TOKEN` shared secret before use
- Both plugins must be mounted on the host composition; they cannot be placed in an agent preset isolate realm
- Depends on the `ws` library as a runtime dependency, provided by the host Node.js environment
- Messages sent via `interconnect_send` have `source: { kind: 'plugin', plugin: 'dsh-interconnect' }` (not `kind: 'user'`), which receiving agents may need to handle specially
dsh-interconnect DSH plugin: from the repository README
Quoted from the Chinesezjc/dsh-interconnect README, the upstream source of the dsh-interconnect DSH plugin. Copyright remains with the original authors.
跨实例消息互通与事件通知插件，用于 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH)。 让一个 DSH 实例能向同一个实例、另一台机器、或另一台机器上的别的 DSH 实例发送消息、探测活性，并在实例之间双向推送事件。 ## 包含两个插件 **`interconnect`** —— host 服务（`ctx.interconnect`）： - `send` / `ping` HTTP 端点（`/interconnect/*`）：跨实例、跨机器投递消息、探测活性 - `/interconnect/link` WebSocket 端点：双向实时事件推流，含心跳与指数退避重连 - 事件 fan-out（HTTP + WebSocket），入站事件以 `interconnect/event` 发出 - 共享密钥鉴权（`DSH_INTERCONNECT_TOKEN`，bearer，fail-closed，timing-safe 比较） **`tool-interconnect`** —— 模型可见工具： - `interconnect_send`：向对端实例的指定 session 投递消息 - `interconnect_ping`：探测对端实例活性与身份 ## 安装 本包已发布到 npm：[`dsh-interconnect`](https://www.npmjs.com/package/dsh-interconnect)。 本仓库是一个 DSH profile bundle（根 `package.json` 声明 `dsh.bundle.patch` 指向 根 `cordis.patch.yml`，后者 `insert` 两个插件行）。 ```bash # 从 npm dsh plugin --profile <name> add dsh-interconnect # 或从本地路径（已实测） dsh plugin --profile <name> add file:/path/to/dsh-interconnect ``` registry 上的 tarball 自带 `lib/*.js` 与 `lib/types/**/*.d.ts`，安装时不跑构建。 `dsh plugin add` 会把仓库识别为 bundle 并追加进 profile 的 `dsh.profile.bundles`。重启 web 服务使 host 侧生效。两端实例的 `.credentials.yaml`（或等价凭据源）设置相同的 `DSH_INTERCONNECT_TOKEN` 作为共享密钥。 ## 开发 依赖 [公开的 DeepSeek Harness monore
Read the full READMERepository license: MIT
dsh-interconnect DSH plugin questions
How do I set up dsh-interconnect for two DSH instances?
First, install the plugin on both instances using `dsh plugin --profile <name> add dsh-interconnect`. Then set the same `DSH_INTERCONNECT_TOKEN` in each instance's `.credentials.yaml` (or equivalent credential source). Restart the web service on both sides so the host plugin (`interconnect`) activates. The instances will be able to communicate using the shared token.
Can I use dsh-interconnect without a WebSocket connection?
Yes, the HTTP endpoints (`/interconnect/send` and `/interconnect/ping`) work without WebSocket. However, for real-time bidirectional event push, you need to establish the WebSocket link at `/interconnect/link`. The WebSocket connection includes automatic heartbeat and exponential backoff reconnection for reliability.
What happens if the `DSH_INTERCONNECT_TOKEN` is different on two instances?
Requests will be rejected with a 401 or similar error because the plugin uses bearer token authentication with timing-safe comparison. Both instances must have exactly the same token value. Make sure the token is set identically in the credential configuration of each instance.
Does dsh-interconnect work across different machines?
Yes, it is designed for cross-machine communication. The HTTP and WebSocket endpoints are reachable over the network. You need to ensure the host machines are network-accessible to each other (e.g., no firewall blocking the ports used by the DSH web service). Each instance's web service must be listening on a network interface, not just localhost.
Why can't I put the tools in an agent preset isolate realm?
The `tool-interconnect` plugin also must be placed on the host composition because the `interconnect` host service is not bound via TypeRT's `@Remote`/Gateway pattern. If you move it to an isolate realm, the tool will not be able to inject the `interconnect` service. Always mount both plugins on the host composition as described in the setup.