Groups and access

A group is authorized for a bot when its chat id sits in allowedGroups, in the bot’s admin_groups, or is inherited from a migrated ancestor chat. Which features actually check that is decided feature by feature, not once for the whole bot.

What “authorized” means

collect_authorized_group_ids is the set a chat id needs to land in: the bot’s allowedGroups (memebot.json, read at runtime as allowed_chat_ids), plus bot_state["admin_groups"], plus any chat inherited through bot_state["migrated_chat_ids"] when a basic group upgrades to a supergroup and gets a new id.

is_authorized(ctx) — the check most Telegram-facing features actually call, directly or indirectly — passes on any one of three independent conditions.

The three branches of is_authorized

The general allowlist itself has no maximum size, on the dashboard or from /menu’s Manage Groups picker.

How a group gets authorized

Four ways in

/authorize

Sent by the owner or a platform admin, /authorize authorizes the current chat immediately. Sent by anyone else, it does nothing but silently record the chat as discovered — no reply, no authorization.

In a private chat it replies Authorized for edits. immediately, then authorizes in the background.

In a group it authorizes and checks the bot’s own admin status at the same time, then replies Authorized (<chat_id>). — with an extra line, To unlock image editing and full functionality, promote me to admin in this group., appended when the bot isn’t an admin there yet.

On failure: a transient Couldn't authorize this group — please try again.

/getid

Anyone can send /getid, in any chat. It always replies with the plain numeric chat id and records the chat as discovered. When the sender is the owner or a platform admin, the chat is additionally authorized in the same step — a second, quieter path into allowedGroups that doesn’t look like an authorization command at all.

One exception: a platform admin sending /getid in a private chat that isn’t the bot owner’s own DM instead adds that chat to the bot’s admin_groups and gets the reply Approved — no discovery record, no allowedGroups entry.

The /menu Manage Groups picker

Tapping a row in the picker behind /menu → Manage Groups authorizes or removes that one group. Full mechanics — the row format, Add Groups, every refusal text — are covered where the picker is introduced.

• The Manage Groups picker

The dashboard Groups tab

“Discovered Groups” opens a modal listing chats the bot has seen but hasn’t authorized yet — a live merge of the bot’s own discovered list and its current admin memberships, with already-authorized chats filtered out. Select any number and tap Authorize (n).

“Authorize A DM” opens a single-field modal for pre-authorizing one Telegram username for DM generations — see DM authorizations below.

/start in the owner’s own DM also authorizes that DM automatically, the first time, as a side effect of pinning the owner’s user id.

Note

A private Telegram invite link (t.me/+…, /joinchat/…, tg://join?invite=…) can never be resolved by a bot account — Telegram’s own MTProto call for it answers BOT_METHOD_INVALID. /getid, sent inside the group itself, is the way in for a group reached only through a private invite link — for the general allowlist and for the buy bot’s own target list alike.

How one is removed

Two ways out

Dashboard confirm modal, titled Remove Group: Are you sure you want to remove {name} from the allowed list? Image generation will be disabled in this chat. Buttons Cancel / Remove (busy: Removing...).

Warning

There is no /deauthorize or /unauthorize command anywhere in the fleet. Removing a group is picker- or dashboard-only.

With zero authorized chats, the dashboard shows: No chats are authorized. Image generation is currently disabled for this bot.

DM authorizations

A DM authorization pre-clears one Telegram username for the same access an allowed group gets, but only inside that username’s own private chat with the bot — never in any group — and it doesn’t let that username authorize anything else.

DM-authorized usernames

Dashboard info text, verbatim: “The telegram username you enter will be authorized for generations in DMs. The user will not be able to authorize other groups. You can revoke their permissions at any time, and that change takes effect immediately.”

Revoke from the same tab’s trash icon. Confirm modal: Are you sure you want to revoke @{username}? They will lose DM access on their next message. Buttons Cancel / Revoke (busy: Revoking...).

The dashboard Groups tab

On-screen title: Allowed Groups. Subtitle: “{owner} can send /authorize to instantly unlock {bot} anywhere. Anyone can send /getid to discover a chat, but only you can authorize them below.”

The four row kinds

Empty state, only when the allowed, demo, and DM lists are all empty: No authorized chats yet. Click "Discovered Groups" or "Authorize A DM" to get started.

What the allowlist gates

A comment inside the /menu root menu’s own code describes allowedGroups as a list “every feature reads.” Read against the features themselves, that isn’t so: each one that cares about group authorization checks it independently, at its own call site, and several never check it at all.

There’s no single gate for it either. _dispatch_webhook — the function every incoming message passes through — has no one check that authorizes or refuses a chat before anything else runs; each step downstream decides for itself.

Consults the group allowlist

Does not consult the group allowlist — gated only by its own feature switch, or not gated at all

Authorization is decided per feature, not once at dispatch. Where a feature does check the allowlist and the check fails, the outcome is silent — the message is consumed and nothing is sent back.

• Who can start a raid
• MP3 downloader
• Groups and deauthorization (X automations)
• The calls commands

The buy bot’s separate pool

The buy bot keeps its own list of posting targets — memebot.json → bots[].buyBot.targetGroupIds — entirely separate from allowedGroups. Capped at 10: MAX_TARGETS in the bot’s buy-bot controller and MAX_TARGET_GROUPS in the dashboard’s buy-bot service are both 10.

Sending /enablebuybot in a group writes to both lists in the same step: it authorizes the group on the general allowlist, and adds it as a buy-bot posting target.

Warning

Removing a group from the allowlist — from the /menu picker or the dashboard Groups tab — does not remove it from the buy bot’s target list, and does not stop buys from posting there. The two lists are independent; only the buy bot’s own Manage Groups (/buybotgroups, or the settings card’s Manage Groups button) removes a buy-bot target.

• Buy bot setup
• Manage Groups — buy bot’s picker