Configuration

Configuration for csp-bot is driven by ccflow. ccflow leverages Pydantic for type validation, and combines it with Hydra / OmegaConf for config-driven initialization. The ccflow examples provide a nice overview of its functionality.

In csp-bot, this means commands, backends, and their settings are all controlled from a small set of composable yaml files.

Two config groups

csp-bot exposes two Hydra config groups:

• gateway — assembles the bot module and the csp-gateway server around it.
• backend — one fragment per chat platform (slack, discord, symphony, telegram), each contributing its configuration to the bot.

The backend group is what makes running against any mix of platforms easy. Because each fragment writes to a different field of the bot config, you can select any combination of them at once.

Selecting backends

The bare bot gateway has no backends of its own. Add backends by listing them from the backend group:

# One backend
csp-bot-start +gateway=bot +backend='[slack]'

# Any combination — no dedicated config required
csp-bot-start +gateway=bot +backend='[slack,telegram]'
csp-bot-start +gateway=bot +backend='[slack,discord,symphony,telegram]'

Each backend reads its credentials from environment variables, so nothing else is required on the command line. See Backends for the full list of variables.

Pre-canned gateways

For the common cases, ready-made gateway configs select the backends for you:

Gateway	Backends
+gateway=slack	Slack
+gateway=discord	Discord
+gateway=symphony	Symphony
+gateway=telegram	Telegram
+gateway=mixed	Slack + Discord
+gateway=all	Slack + Discord + Symphony + Telegram
+gateway=bot	none — add your own with +backend

csp-bot-start +gateway=all

Using a local config file

Selecting backends from the command line is convenient, but a small yaml file is easier to version and share. Hydra unions configs, so a local file only needs to declare which gateway it builds on:

example/bot/slack.yaml

# @package _global_
defaults:
  - /gateway: slack
  - _self_

bot_name: CSP Bot

# Tokens are read from the environment: SLACK_BOT_TOKEN, SLACK_APP_TOKEN
# csp-bot-start --config-dir=example +bot=slack

To pick your own mix of backends in a file, build on the bare bot gateway and list them:

example/bot/custom.yaml

# @package _global_
defaults:
  - /gateway: bot
  - /backend:
      - slack
      - telegram
  - _self_

bot_name: CSP Bot

Run either with:

csp-bot-start --config-dir=example +bot=slack
csp-bot-start --config-dir=example +bot=custom

What a gateway config expands to

A gateway config is built from the bare bot skeleton plus the selected backend fragments. The bot gateway defines the bot module and an empty BotConfig:

# @package _global_
defaults:
  - /modules
  - _self_

bot_name: CSP Bot

modules:
  bot:
    _target_: csp_bot.Bot
    config:
      _target_: csp_bot.BotConfig

Each backend fragment fills in one field of that BotConfig. For example, the slack fragment:

# @package modules.bot.config
slack:
  _target_: csp_bot.SlackConfig
  bot_name: ${bot_name}
  config:
    _target_: chatom.slack.SlackConfig
    bot_token: ${oc.env:SLACK_BOT_TOKEN}
    app_token: ${oc.env:SLACK_APP_TOKEN}

Selecting +backend='[slack,telegram]' merges the slack and telegram fragments into the same BotConfig, leaving the unused backends unset. The per-platform config block is the corresponding chatom backend config, so any field that backend supports can be set here.

All of these configs live in-source under csp_bot/config; copy or extend them as the basis for your own.