Telegram меняет MTProto.
Что готовить к июню 2026.

Telegram публикует изменения MTProto через API Layers. Каждый layer — инкремент: добавляются методы, помечаются deprecated, меняется схема некоторых типов. Текущий layer (по состоянию на момент публикации статьи) — ~180.

Большинство обновлений — мягкие. Telegram редко ломает обратную совместимость в один день. Типичный flow: новый метод появляется → старый помечается deprecated → deprecated работает ещё 6-12 месяцев → потом удаляется.

Но в 2026 ожидается крупная consolidation — одновременно несколько переходов, которые суммарно сделают старые самописные клиенты неработоспособными. Вот что конкретно.

Session-string v2: что меняется

Session-string — это сериализованный auth-ключ, с которым твой клиент входит в Telegram без повторной авторизации. Исторически разные клиенты использовали разные форматы: telethon — pickle+base64, pyrogram — custom binary.

Telegram двигается к стандартизированному формату с обратной совместимостью. Новый формат содержит:

• Version tag (1 байт) — для future migrations
• DC id + auth_key (256 байт) — как раньше
• Device fingerprint metadata — app_version, device_model, system_version хранятся в session-string (не задаются per-call)
• Creation timestamp — для detection aging

Что ломается: клиенты, которые генерировали session-string раньше и передавали fingerprint в каждом подключении, должны теперь включать fingerprint в сам session. Иначе — Telegram возвращает AUTH_KEY_UNREGISTERED.

Новые flood headers: более детальное rate-limiting

Классический FLOOD_WAIT_X — единственный способ Telegram сказать «подожди». В новой схеме появляются дифференцированные headers:

Разделение даёт Telegram возможность таргетированно замедлять без блокировки всего аккаунта. Для клиентов это означает: нужно различать типы FloodWait и соответственно обрабатывать.

Endpoints, которые уходят

По наблюдаемым паттернам deprecation, следующие методы в зоне риска:

• auth.importAuthorization — используется для переноса сессии между DC. Заменяется на server-side автоматический DC-аффинити.
• channels.GetParticipants с фильтром ChannelParticipantsRecent — возвращал последних N участников. Заменяется на channels.GetStatistics для агрегаций.
• messages.SearchGlobal — глобальный search по всем чатам. Ужесточается — будет доступен только Premium-аккаунтам.

Что делать клиентам на telethon / pyrogram

Если у тебя свой fork одной из популярных Python-библиотек:

1. Обнови до latest — автор библиотеки обычно патчит новые layer за 1-3 недели. Следи за GitHub releases.
2. Мигрируй session storage — если ты кеширует session-strings в своей БД, нужно перегенерировать все сессии под v2 формат.
3. Различай FloodWait subtypes — вместо одной except FloodWait используй 3-4 разных с соответствующим handling.
4. Логируй warning'и — Telegram часто шлёт non-fatal warnings за deprecated methods. Если их не логируешь — пропустишь предстоящий deprecation.

Если TDLib

Обновление TDLib — автоматически тянет все schema changes. Обычно просто git pull && rebuild. Изменения в session format — чаще всего прозрачные (библиотека делает re-encoding в фоне).

Если SaaS

Вопрос к твоему вендору: «когда планируется миграция на новый MTProto layer?». Нормальный ответ — «уже сделано, клиенты не заметили». Если ответ «когда-нибудь в будущем» — флаг.

Почему нас не волнуют миграции

У нас MTProto-клиент написан на уровне TDLib custom fork + собственный schema layer. Изменения API обрабатываются централизованно:

• Мониторим Telegram GitHub и core.telegram.org ежедневно
• Бета-тестируем новые layer на тест-аккаунтах за 1-2 недели до прод выката
• Push обновлений клиентам — прозрачно, через автообновление desktop-приложения
• Session storage на нашей стороне — переконвертация при первом коннекте

Для пользователя это значит: ты не думаешь о MTProto. Telegram меняет layer → ты этого не замечаешь.