<!-- source: https://deepwiki.com/qhkm/zeptoclaw/7.8-other-channels -->

# Other Channels

- .cargo/config.toml
- .config/nextest.toml
- docs/ACP_IMPLEMENTATION.md
- docs/claude/configuration.md
- examples/riscv_smoke.rs
- src/agent/context_monitor.rs
- src/channels/acp.rs
- src/channels/acp_http.rs
- src/channels/acp_protocol.rs
- src/channels/discord.rs
- src/channels/lark.rs
- src/channels/mqtt.rs
- src/channels/plugin.rs
- src/channels/serial.rs
- src/channels/slack.rs
- src/channels/webhook.rs
- src/channels/whatsapp_cloud.rs
- src/providers/gemini.rs
- src/tools/docx_read.rs
- src/tools/reminder.rs
- tests/acp_acpx.rs

This page documents channels beyond the major messaging platforms (Telegram, Slack, Discord, WhatsApp, Email, Lark). ZeptoClaw supports webhook-based integrations, hardware serial communication, MQTT for IoT devices, the Agent Client Protocol (ACP), and a plugin system for custom channel implementations.

For the core channel architecture and trait definitions, see **7.1 Channel Architecture**.

## Overview

ZeptoClaw provides several additional channel types, each catering to different integration patterns:

All channels implement the `Channel` trait and integrate with the `MessageBus` for uniform message routing.

**Sources:** [src/channels/webhook.rs191-196](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L191-L196) [src/channels/serial.rs67-76](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/serial.rs#L67-L76) [src/channels/mqtt.rs87-97](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L87-L97) [src/channels/plugin.rs115-130](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/plugin.rs#L115-L130) [src/channels/acp.rs83-94](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp.rs#L83-L94) [src/channels/acp_http.rs167-189](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp_http.rs#L167-L189)

## Webhook Channel

### Architecture and Data Flow

The `WebhookChannel` acts as a lightweight HTTP server using `tokio::net::TcpListener`. It parses raw HTTP streams into structured `InboundMessage` objects.

```

```

**Sources:** [src/channels/webhook.rs68-79](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L68-L79) [src/channels/webhook.rs171-181](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L171-L181) [src/channels/webhook.rs242-260](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L242-L260) [src/channels/webhook.rs364-410](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L364-L410)

### Security Mechanisms

1. Bearer Token : Validated using constant_time_eq src/channels/webhook.rs 68 to prevent timing attacks.
2. HMAC Signatures : Supports X-ZeptoClaw-Signature-256 headers using hmac_sha256_hex src/channels/webhook.rs 81
3. Payload Limits : Enforces MAX_BODY_SIZE (1MB) and MAX_HEADER_SIZE (8KB) src/channels/webhook.rs 109-112

## Agent Client Protocol (ACP) Channels

ZeptoClaw implements the Agent Client Protocol (ACP) in two forms: a standard stdio-based channel and a streamable HTTP channel.

### ACP Stdio Channel

The `AcpChannel` [src/channels/acp.rs83](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp.rs#L83-L83) allows ZeptoClaw to act as an ACP-compliant agent. It reads JSON-RPC from `stdin` and writes to `stdout`.

- Key Methods : Supports session/new , session/prompt , and session/cancel src/channels/acp.rs 4-6
- State Management : Uses AcpState to track sessions (mapping IDs to working directories) and pending prompts src/channels/acp.rs 47-54
- Cleanup : Implements sweep_expired to remove idle sessions based on a TTL src/channels/acp.rs 67-80

### ACP HTTP Channel

The `AcpHttpChannel` [src/channels/acp_http.rs167](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp_http.rs#L167-L167) provides a modern web interface for ACP.

- Transport : Uses Server-Sent Events (SSE) to stream session/update notifications and final results back to the client src/channels/acp_http.rs 5-13
- Concurrency : Manages connections with a JoinSet and uses oneshot channels to bridge the asynchronous agent reply from the MessageBus back to the specific HTTP handler src/channels/acp_http.rs 180-188

**Sources:** [src/channels/acp.rs1-14](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp.rs#L1-L14) [src/channels/acp.rs47-80](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp.rs#L47-L80) [src/channels/acp_http.rs1-21](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp_http.rs#L1-L21) [src/channels/acp_http.rs109-155](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/acp_http.rs#L109-L155)

## Serial/UART Channel

The `SerialChannel` (enabled via `hardware` feature) allows embedded devices (ESP32, Arduino) to communicate with the agent over physical or virtual COM ports.

### Implementation Details

- Library : Uses tokio-serial for async I/O src/channels/serial.rs 39
- Framing : Messages must be newline-delimited JSON strings.
- Concurrency : Uses a BufReader in a background task to poll the read_half of the serial stream src/channels/serial.rs 136-142

### Data Structure

**Sources:** [src/channels/serial.rs50-64](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/serial.rs#L50-L64) [src/channels/serial.rs130-160](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/serial.rs#L130-L160)

## MQTT Channel

The `MqttChannel` (enabled via `mqtt` feature) uses the `rumqttc` library to provide pub/sub capabilities for IoT fleets.

### Topic Structure

The channel follows a specific convention for routing messages to and from devices:

- Inbox : zeptoclaw/inbox/{device_id} — Device sends to Agent src/channels/mqtt.rs 20
- Outbox : zeptoclaw/outbox/{device_id} — Agent replies to Device src/channels/mqtt.rs 21

### Event Loop

The channel spawns a background task that calls `eventloop.poll()` [src/channels/mqtt.rs174](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L174-L174) When a `Packet::Publish` is received, it extracts the `device_id` using `extract_device_id` [src/channels/mqtt.rs82](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L82-L82) and routes it to the `MessageBus`.

**Sources:** [src/channels/mqtt.rs82-84](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L82-L84) [src/channels/mqtt.rs170-185](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L170-L185)

## Channel Plugin System

The `ChannelPluginAdapter` allows developers to write channels in any language. The plugin is a long-running binary that communicates with ZeptoClaw via JSON-RPC 2.0 over stdin/stdout.

### Plugin Lifecycle

```

```

**Sources:** [src/channels/plugin.rs115-130](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/plugin.rs#L115-L130) [src/channels/plugin.rs190-210](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/plugin.rs#L190-L210)

### Manifest Configuration

Plugins are defined by a `manifest.json` file [src/channels/plugin.rs21-32](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/plugin.rs#L21-L32) The `ChannelPluginManifest` struct [src/channels/plugin.rs86-101](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/plugin.rs#L86-L101) tracks:

- binary : Path to the executable.
- env : Custom environment variables.
- timeout_secs : Timeout for RPC calls (default 30s).

## WhatsApp Cloud API Channel

Unlike the legacy bridge-based implementation, the `WhatsAppCloudChannel` [src/channels/whatsapp_cloud.rs163](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/whatsapp_cloud.rs#L163-L163) integrates directly with Meta's Graph API.

### Architecture

- Inbound : Listens for HTTP webhooks from Meta. It implements GET /whatsapp for verification challenges src/channels/whatsapp_cloud.rs 8 and POST /whatsapp for message notifications src/channels/whatsapp_cloud.rs 9
- Outbound : Sends messages via https://graph.facebook.com/v18.0/{phone_number_id}/messages src/channels/whatsapp_cloud.rs 13
- Security : Verifies webhook signatures using hmac_sha256_hex src/channels/whatsapp_cloud.rs 179 and constant-time comparison src/channels/whatsapp_cloud.rs 165

**Sources:** [src/channels/whatsapp_cloud.rs1-32](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/whatsapp_cloud.rs#L1-L32) [src/channels/whatsapp_cloud.rs163-177](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/whatsapp_cloud.rs#L163-L177) [src/channels/whatsapp_cloud.rs179-204](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/whatsapp_cloud.rs#L179-L204)

## Summary of Implementation Logic

All "Other Channels" share a common initialization pattern in the `factory`:

1. Configuration Check : Verify if the channel is enabled in config.json .
2. Base Config : Create a BaseChannelConfig containing the name and allowlist src/channels/webhook.rs 61
3. Start Hook : Call start() , which typically spawns a tokio::spawn background loop src/channels/mqtt.rs 170
4. Message Conversion : Map platform-specific JSON (e.g., MqttInbound src/channels/mqtt.rs 54 ) to the internal InboundMessage type.

**Sources:** [src/channels/webhook.rs222-240](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/webhook.rs#L222-L240) [src/channels/serial.rs130-140](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/serial.rs#L130-L140) [src/channels/mqtt.rs124-150](https://github.com/qhkm/zeptoclaw/blob/2c743d31/src/channels/mqtt.rs#L124-L150)
