Telegram-софт: native-клиент,
а не адаптер над Bot API.

Если ты когда-нибудь смотрел на рынок «Telegram-автоматизаций» и задавался вопросом, почему одни тулы работают на 10 аккаунтов и 100 сообщений в час, а другие ломаются на пятом получателе — дело не в «качестве кода». Дело в том, на каком уровне протокола софт разговаривает с Telegram.

Почти весь массовый Telegram-софт — это generic CRM / outreach-платформа, к которой прикрутили адаптер под Telegram Bot API. Снаружи выглядит одинаково: «отправка сообщений в Telegram». Внутри — разница в сто раз по тому, что тулу доступно и как он переживает ошибки.

Bot API vs MTProto — в чём разница

У Telegram две точки входа для сторонних клиентов:

• Bot API (api.telegram.org) — HTTP-обёртка. Работает только от имени бота (@YourBot). Для бота нужен токен от BotFather. Простой в использовании, документация в одном файле.
• MTProto (core.telegram.org/mtproto) — официальный бинарный протокол, на котором работают сам Telegram Desktop, iOS и Android-клиент. Используется либо через TDLib (C++), либо через обёртки pyrogram / telethon (Python).

Почему это важно: через Bot API нельзя сделать то, что может обычный пользовательский клиент. Бот не видит список диалогов, не может вытащить участников публичного канала (только если добавить бота админом), не умеет читать сообщения в чатах, где он не состоит.

Для outreach и парсинга Bot API — тупик. Он спроектирован для интерактивных ботов (@GmailBot, @WeatherBot), а не для работы со списком каналов, парсинга участников и массовой отправки.

Что умеет native-клиент и не умеет adapter

Native MTProto-клиент — это твой Telegram, просто запущенный программно. Сессия логинится через auth.sendCode + auth.signIn, как в обычном Desktop-клиенте. Дальше доступен весь API пользователя:

Это не «расширенные возможности». Это базовые функции Telegram, которыми пользуется обычный человек в приложении. Для парсинга аудитории, outreach и CRM-интеграции они все обязательны.

Generic SaaS с Bot API-адаптером умеет ровно одно: отправлять сообщения тем, кто первым написал боту. Всё остальное приходится допиливать сбоку — обычно через «загрузите CSV с username'ами, мы попытаемся их найти». Работает плохо: без resolveUsername адаптер не умеет получить InputPeer, без InputPeer не умеет ничего.

Ошибки Telegram на уровне протокола

Второе принципиальное отличие — как тул переживает ошибки. MTProto определяет десятки классов ошибок, и на каждый адекватная реакция разная. Generic SaaS с HTTP-адаптером видит только 400 / 429 / 500 и делает ретрай через N секунд. Этого мало.

Правильная реакция на PEER_FLOOD — не «подожди 60 секунд и повтори». Это сигнал, что аккаунт уже в restricted-состоянии. Если продолжать отправлять — через 2-3 часа прилетит бан от @SpamBot. Native-клиент должен немедленно остановить sending от этого аккаунта и перевести его в cooldown на 24-72 часа.

SESSION_REVOKED значит: юзер (или Telegram безопасность) разлогинил твою сессию с другого устройства. Ретраить тот же auth-key бессмысленно — он уже не работает. Native-клиент удаляет session-file и либо алертит в UI, либо инициирует re-login через SMS. Generic SaaS просто ретраит 5 раз и сдаётся.

Почему 2026-й ломает тулы без entity-cache

Telegram использует сложную систему peer-идентификаторов: user_id + access_hash, channel_id + access_hash. Чтобы отправить сообщение в канал, нужно знать оба значения. access_hash выдаётся сервером на конкретную сессию — использовать его от другой сессии нельзя.

Это называется entity caching: native-клиент должен хранить таблицу peer_id → access_hash и обновлять её, когда получает новые значения в updates. Без этого:

• Ты парсишь участников канала → получаешь user_id'ы. Но без access_hash написать им невозможно.
• Ты импортируешь список @username → резолвишь через resolveUsername → получаешь peer. Но если кэш не сохранился между запусками, на следующий день нужно резолвить снова — и Telegram начинает лимитировать резолв.
• Ты сделал получателю 10 сообщений за день, а на 11-м тул говорит «пользователь не найден». Причина — потерян access_hash в кэше.

Native-клиенты (TDLib, pyrogram) решают это из коробки: есть встроенная таблица peers, синхронизация через updates, правильная инвалидация. Generic SaaS-адаптеры часто кэшируют только user_id — и ломаются на операциях, которые требуют access_hash.

Ключи локально — ключевой принцип

Ещё одно отличие native от cloud-SaaS: где хранится auth-key сессии.

• Native (TG:ON): session-file лежит на твоей машине. SQLite + шифрование (ключ в Keychain/DPAPI). Можно экспортировать, бэкапить, переносить между машинами. Владелец — ты.
• Cloud SaaS: session-file у вендора. Ты не имеешь прямого доступа к auth-key. Вендор может технически его использовать, копировать, потерять при инциденте. При расторжении контракта сессии остаются у них.

С точки зрения инженерии это anti-pattern для cloud-SaaS. Auth-key — это по сути пароль+2FA в одном объекте. Хранить такие ключи массово у третьей стороны — всё равно что отдать пароли от банк-аккаунтов в облачный CRM. Работает, пока вендор честен и его не взломают.

Когда adapter'а хватает, а когда нет

Честное разделение: не всем нужен native-клиент.

Если у тебя workflow из первых трёх строк — не трать деньги на native-клиент, хватит любого бота. Если из остальных — любой «Telegram-софт без MTProto» будет ломаться на каждой нетривиальной операции. Это вопрос не фич, а архитектуры.

Адаптер ≠ native-клиент

«Telegram automation» — маркетинговое слово. Полезная часть в нём — только то, что тул реально умеет делать с MTProto напрямую. Всё остальное — красивый UI над Bot API, который ломается на первой серьёзной операции.

Проверяй перед покупкой: умеет ли тул парсить участников публичного канала (не админом)? Умеет ли доставать историю переписки из своих диалогов? Где лежит session-файл, можно ли его экспортировать? Как реагирует на PEER_FLOOD? Если ответы «нет/нет/у нас/ретраит» — это адаптер.

TG:ON native с первого дня. TDLib + pyrogram под капотом, session-файлы локально, корректная обработка всех классов протокольных ошибок. Скачивается одним бинарником, ключи остаются у тебя.