Social Channels

Broadcast / social-feed integrations. These differ from chat channels in two ways: messages are typically public, and the agent often acts as a poster rather than a bidirectional responder.

Build note: Social channels are not included in the lean default build. To use them, build with --features channels-full (all channels) or the specific feature flag (e.g. --features channel-twitter). Prebuilt binaries do not include these channels by default. See Channels → Overview for the full build-options table.

Bluesky (AT Protocol)

• Auth: Bluesky app-password (not your real password). Create one in settings.
• Outbound: 300-character posts; longer responses auto-thread.
• Protocol: AT Protocol via the atrium-api crate.

Nostr

Inbound senders are gated against the peer set resolved for the bound agent, drawn from the peer_groups config the agent belongs to. Matching strips a leading @ and is case-insensitive against the channel’s native sender identifier. An empty set denies everyone; a set containing "*" accepts anyone; otherwise only the listed external peers (and peer agents) are accepted. This is separate from gateway pairing (gateway.require_pairing), which authenticates HTTP/WebSocket clients, not chat-channel senders.

A peer group for nostr sets channel to nostr, lists the allowed senders in external_peers (for nostr, the sender’s hex public key; ["*"] accepts anyone), optionally names peer agents for cross-agent dispatch, an ignore blocklist, and an output_modality (mirror, voice, or text). See Peer Groups for the field reference.

Where to set this:

• Auth: raw private key (nsec bech32 or hex).
• Inbound: kind-1 (text), kind-4 (DM, NIP-04), and kind-1059 (gift-wrap, NIP-17).
• Outbound: same kinds. Zap handling is experimental.
• Relays: the agent connects to all listed relays; use 3–5 for reliability. If relays is omitted, ZeroClaw connects to a built-in set of popular public relays.

Twitter / X

Inbound senders are gated against the peer set resolved for the bound agent, drawn from the peer_groups config the agent belongs to. Matching strips a leading @ and is case-insensitive against the channel’s native sender identifier. An empty set denies everyone; a set containing "*" accepts anyone; otherwise only the listed external peers (and peer agents) are accepted. This is separate from gateway pairing (gateway.require_pairing), which authenticates HTTP/WebSocket clients, not chat-channel senders.

A peer group for twitter sets channel to twitter, lists the allowed senders in external_peers (for twitter, the Twitter/X @username; ["*"] accepts anyone), optionally names peer agents for cross-agent dispatch, an ignore blocklist, and an output_modality (mirror, voice, or text). See Peer Groups for the field reference.

Where to set this:

• Auth: Twitter API v2 OAuth 2.0 Bearer Token only.
• Inbound: mentions via the Filtered Stream endpoint.
• Outbound: posts, replies, threads.
• Caveat: the free tier is rate-limited to the point of near-uselessness. Budget accordingly.

Reddit

• Auth: OAuth 2.0 with a refresh token. Generate one with a script-type Reddit app and the password or code flow.
• Inbound: new posts and comments in the configured subreddits (or all subreddits the bot has access to when subreddits is empty), plus replies to the agent’s own posts.
• Outbound: posts, comments, private messages.

Operating social channels safely

Bots on public social networks attract adversarial input. Two precautions:

1. Restrict who the agent will respond to. Gate inbound senders with a peer group (per channel, above): an empty peer set denies everyone, ["*"] accepts anyone. Bluesky has no peer-group sender field; gate at the autonomy / tool layer instead.
2. Keep autonomy level at Supervised or lower. A public-facing agent in Full autonomy is effectively a public shell. For public-facing channels, restrict the tool surface in the global tool-policy config rather than expecting per-channel tools_allow (no such per-channel field exists).

Rate limits and backoff

All social channels are subject to aggressive rate limits. ZeroClaw’s outbound queue uses exponential backoff on 429 responses. If you hit persistent rate-limiting, throttle the agent’s posting cadence at the source rather than relying on per-channel streaming knobs (none of these channels expose draft-update intervals; their schema is intentionally minimal).