#Can I create Multi thread support like krill and how?

1 messages · Page 1 of 1 (latest)

neat lotus
#

Can I create Multi thread support like krill and how to do that in telegram?

languid vortexBOT
quiet epochBOT
#

Yep, but on Telegram the equivalent is topics, not Discord-style threads.

How to do it:

  1. Make the Telegram chat a forum-enabled supergroup.
  2. Add your bot there.
  3. Configure per-topic routing, for example:
{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "1": { agentId: "main" },
            "3": { agentId: "coder" },
# 
            "5": { agentId: "support" }
          }
        }
      },
      threadBindings: {
        spawnSubagentSessions: true,
        spawnAcpSessions: true
      }
    }
  }
}

What that gives you:

  • each Telegram topic gets its own isolated session
  • each topic can use a different agent
#
  • ACP sessions can bind to a topic with /acp spawn <agent> --thread auto
  • you can also bind an existing topic with /focus <target>

A couple important details:

  • for Telegram, this is mainly for forum topics in groups/supergroups
  • OpenClaw stores them as chatId:topic:topicId
  • OpenClaw can also create Telegram topics via the topic-create action

Docs:

If you want, I can give you a complete working Telegram config for your exact use case, like “one topic per agent” vs “spawn a fresh topic per Codex session.”

neat lotus
#

Can I create Multi thread support like krill and how to do that in telegram?

quiet epochBOT
#

Yes, but in Telegram it’s topics, not Discord threads.

If you want Krill-style “multiple thread/workspace” behavior in Telegram:

  1. Use a forum-enabled Telegram supergroup
  2. Add your bot
  3. Configure per-topic routing, for example:
{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "1": { agentId: "main" },
# 
            "2": { agentId: "support" },
            "3": { agentId: "coder" }
          }
        }
      },
      threadBindings: {
        spawnSubagentSessions: true,
        spawnAcpSessions: true
      }
    }
  }
}

That gives you:

  • one separate session per topic
neat lotus
#

but there will be so may topics for different people?

quiet epochBOT
#

Yeah, that’s the downside. If you do 1 topic per person, it can get messy fast.

I’d usually recommend one of these instead:

  1. One shared topic

    • simplest
    • good for small groups

  2. A few fixed topics

    • like support, coding, random, ops
    • best balance for Telegram

  3. DM for personal conversations, group topics for shared ones

    • probably the cleanest setup

So technically, yes, you can do per-person topics, but I wouldn’t recommend it unless the group is small or you auto-clean/archive them.

#

If you want Krill-like support in Telegram, I’d do:

  • group topics by purpose
  • DM for user-specific threads

If you want, I can sketch the best Telegram architecture for:

  • small community
  • support server
  • per-user private assistant
neat lotus
#

so i need to turn off allowlist? how is that safe

quiet epochBOT
#

No, you do not need to turn off allowlist.

Safer setup is:

  • keep the group itself allowlisted under channels.telegram.groups
  • keep groupPolicy: "allowlist"
  • allow only specific people with groupAllowFrom or per-group/per-topic allowFrom

So safety is split into two checks:

  1. Which Telegram groups are allowed
  2. Which users inside those groups are allowed

Example:

# 
{
  channels: {
    telegram: {
      groupPolicy: "allowlist",
      groups: {
        "-1001234567890": {
          requireMention: true,
          allowFrom: ["123456789", "987654321"], // only these users
          topics: {
            "42": {
              allowFrom: ["123456789"] // optional tighter rule for one topic
            }
          }
        }
      }
# 
    }
  }
}

So:

  • groupPolicy: "open" = anyone in that allowed group can talk to the bot
  • groupPolicy: "allowlist" = only approved users can

If you’re worried about safety, I’d keep:

  • groupPolicy: "allowlist"
  • requireMention: true
  • explicit allowFrom / groupAllowFrom

That’s the safe version.