Two Telegram instances

JID prefixes are declarations, not configuration. Each adapter declares what it owns; the gateway follows.

You have two Telegram bots serving different groups of users. Both bots handle telegram: JIDs. The gateway's prefix-scan would be ambiguous — both adapters claim the same prefix. The solution is the JID→adapter mapping: the first inbound message from a chat JID records which adapter it came from, and outbound routing follows that record, not the prefix.

The scenario

qubico_bot serves the krons groups. rhias_bot serves the rhias groups. Both register with prefixes: ["telegram:"]. Groups for qubico users were onboarded via qubico_bot — their JIDs are mapped to telegram-krons. Groups for rhias users are mapped to telegram-rhias.

Service config for the second bot

Add a second service TOML. The only differences are the channel name, the bot token env var, and the listen address:

# /srv/data/arizuko_myinstance/services/teled-rhias.toml
image      = "arizuko:latest"
entrypoint = ["teled"]

[environment]
CHANNEL_NAME      = "telegram-rhias"
TELEGRAM_BOT_TOKEN = "${TELEGRAM_BOT_TOKEN_RHIAS}"
LISTEN_ADDR       = ":9003"
LISTEN_URL        = "http://teled-rhias:9003"
ROUTER_URL        = "http://gated:8080"
CHANNEL_SECRET    = "${CHANNEL_SECRET}"

The first bot service (teled) uses CHANNEL_NAME = "telegram-krons" and LISTEN_ADDR = ":9002". Both register the same prefix. This is intentional.

Add the bot tokens to .env

# /srv/data/arizuko_myinstance/.env
TELEGRAM_BOT_TOKEN_KRONS=123456:ABC...
TELEGRAM_BOT_TOKEN_RHIAS=789012:XYZ...

How routing works

On the first inbound message from a chat JID, the adapter includes its name in the message payload. The gateway calls RecordJIDAdapter(chatJID, adapterName) before inserting the message — so the mapping is set before the next poll can process any outbound for that JID.

When the gateway needs to deliver an outbound message:

findChannel(jid) checks the jidAdapters sync.Map first
If found: route to the recorded adapter by name
If not found: fall back to prefix scan across all registered adapters

For existing groups that were onboarded via qubico_bot, their JIDs are already in the map pointing to telegram-krons. New messages from rhias users flow through telegram-rhias and record their own entries. The two bots coexist with zero gateway configuration changes.

Onboarding new groups to the right bot

When using the onboarding flow, the approving operator registers the group while the user's initial message is still in-flight through the correct adapter. The JID→adapter mapping is already set at that point. If you register groups manually:

arizuko group myinstance add telegram:-1001234567890

The first real message from that chat will set the mapping. Until then, the fallback prefix scan picks whichever adapter responds first — so for groups you know belong to a specific bot, send a test message through that bot before going live.

How it fits the system

jidAdapters is a sync.Map populated at message receipt time. It is in-memory and rebuilt from inbound traffic on restart — no separate persistence needed, because the data regenerates naturally as messages flow. The prefix scan is the fallback for cold state only.

Two adapters with identical prefixes do not conflict. The gateway does not need to know that two Telegram bots exist, or that they serve different user populations. The recorded mapping is the routing table. Nothing else is needed.