BetterForward turns Telegram DMs into forum topics for a support group

One topic per user, and the account stays private

BetterForward is designed for better message forwarding in Telegram, and the mechanism is the group topic feature. User private messages to the bot are forwarded into the group, with each user corresponding to an independent topic, so multiple administrators can work on the cases together and the personal account is not directly exposed. That is the whole idea, and it is a specific answer to a specific problem. A support team that receives dozens of DMs has no shared history, and if one admin answers, the other has no idea. Here the conversations become group topics, so they are visible to the team, searchable, and survive a staff change, while the person asking still never learns who answered or what their personal account is. The privacy claim is one directional and worth reading precisely. The user's side of the exchange is not shown to other users, and administrators answer from inside the group rather than from their own accounts. The README notes that the topic feature is what makes this possible, which also means the group must be created with topics enabled and the bot made an administrator with the rights to manage topics and delete messages.

Setup is four steps and a bot token

The quick start is four steps. You create the bot with BotFather and get a token. You create a group with topics enabled and set the bot as an administrator, with the requirement that it can manage topics and delete messages. You get the group id, and the README suggests inviting a helper bot, @sc_ui_bot, and sending /id in the group to obtain it. Then you deploy BetterForward, which is described below as a Docker deployment. The language is one of zh_CN, en_US or ja_JP, and the README says contributions of further translations are welcome. There is also a note that a user can send /help in the group main topic to open the management menu, which is how most of the configuration is done. The last item is worth flagging for anyone assessing the security model, since a management menu driven by a chat command in the group means group permissions are the real access control, and the bot's own permission list determines who can reach it.

Docker is the deployment path, and the environment is small

The deployment section gives both a compose file and a plain run command. The compose file is a single service with the image ghcr.io/sidecloudgroup/betterforward:latest, a restart policy of unless-stopped, and five environment variables, TOKEN, GROUP_ID, LANGUAGE, TG_API and WORKER, with a data volume mounted at ./data. The Docker run form is the same set of variables with a named volume:

docker run -d --name betterforward \
    -e TOKEN=<your_bot_token> \
    -e GROUP_ID=<your_group_id> \
    -e LANGUAGE=zh_CN \
    -e WORKER=2 \
    -v /path/to/data:/app/data \
    --restart unless-stopped \
    ghcr.io/sidecloudgroup/betterforward:latest

The WORKER value is the number of worker threads, and the compose instructions say to raise it somewhat when traffic is high, so it is a tuning knob rather than a fixed number. TG_API is the custom Telegram API address, and leaving it empty uses the official API, which is also how you point the bot at a local Bot API server if you run one. The image itself is built from python:3.12-alpine, with the locale files copied in, the requirements installed, and the entrypoint passing the settings as command line arguments. The Python dependencies are four, with pyTelegramBotAPI pinned at 4.37.0, diskcache for caching, pytz for timezones and httpx with the http2 extra.

Auto replies, spam filtering and human verification

Beyond forwarding, the bot has the moderation features a support group needs, all configured from the management menu. Auto replies let you add and manage rules, and the keywords support regular expressions, with a rule able to carry the hours during which it is active. The default message is what a user sees when they first contact the bot. Ban and ban reply let you block a user from sending further messages and configure a canned response for them, which can also be switched off. Spam filtering works by keyword, and a message that matches is moved into a dedicated spam topic without creating a user topic at all, which is the cheapest way to deal with the volume that is not worth a reply. Human verification comes in three forms, selectable in the verification settings. Button verification asks the user to press a button, a mathematical challenge asks a simple arithmetic question, and a third option integrates with TGuard, an advanced verification service, where you configure an API address and key and the verification interface opens as a Telegram Mini App. An admin can also mark a user as verified manually with /verify in the user topic.

Per user message permissions with a global default

The permission system is the most detailed feature and the one with the most operational value for a group that does not want its help channel used as a file drop. The default permission settings control globally whether users can send images, stickers and animated stickers, video, voice, files including documents and audio, links, and @username mentions, all allowed by default and closable individually. There is a separate setting for the reply sent when a user sends a forbidden type, with a customisable template where {permission} is replaced by the type name, and that reply can also be switched off to implement a silent block. Inside a user topic, an admin can adjust that user's permissions individually, with the commands /permissions to view the status, /allow and /disallow to change them, and /resetpermissions to clear the individual settings and fall back to the global default. The type keys are photo, sticker, video, voice, file, link and username, and the word all can operate on every type at once, excluding plain text. A broadcast command sends a notification to all users, and a timezone setting affects the time related features such as the auto replies.

Administrator commands and the shape of the project

The command surface is listed in the README as a table, and the group level commands are /help to open the management menu, /ban to ban the user of the current topic, /unban with an optional user id, /terminate to end the session and delete the topic, /delete to delete a message when replying to it, /verify to mark a user as verified, /setnote and /getnote for topic notes, /refresh to refresh the user information in the topic, and the permission commands. In a private chat with the bot, /help and /delete are available. A separate table covers the per user permission commands with the type arguments. The repository layout is a straightforward Python application, with main.py at the root, src/ for the implementation, a db_migrate/ directory for schema migrations, locale/ for translations, tests/ with a pytest.ini and requirements-dev.txt, and requirements.txt at the root. The licence is MIT, the release history shows v2026.8.1 on 2026-08-28, v2026.5.1 on 2026-05-10 and v2.0.5 on 2025-12-27, the last push was on 2026-10-14, and there is a Telegram channel for the project with issues used for bug reports and feature requests.

Editorial conclusion

Adopt BetterForward when you run a community support group where several administrators answer questions privately and you want those conversations to live in one place without exposing personal accounts. Do not adopt it if you want a simple relay or a channel, since the whole design depends on topic mode and per user topics, and do not deploy it without reading the permission and verification defaults. Verify first that your group has topics enabled and the bot is an administrator able to manage topics and delete messages, that you have a group id, and that the language and worker settings suit your traffic.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SideCloudGroup/BetterForward on GitHub