Maxgram

Maxgram — это личный мост между мессенджером MAX и Telegram. Он поднимет неофициальный userbot на WebSocket, который будет зеркалить каждый чат из MAX в отдельную тему Telegram-форума и отправлять ответы обратно. Нужен тем, кого школа или госучреждение обязали пользоваться MAX: можно читать и отвечать на все переписки из Telegram, вообще не устанавливая MAX.

Логика простая. Каждый диалог или группа в MAX превращается в отдельный топик супергруппы-форума, причём тема создастся автоматически при первом же сообщении. Пишешь ответ в топик — он уйдёт в MAX, в том числе как reply на конкретное сообщение. Ответы из MAX, в свою очередь, станут нативными ответами в Telegram, если привязка исходного сообщения сохранилась; иначе рядом появится короткий контекстный маркер без цитаты. В итоге вместо мешанины уведомлений получается аккуратная папка тем: «Классный чат», «Спортивная секция», «Контакт по имени».

Задача непростая: у MAX нет официального клиента для Telegram и нет открытого API — всё реверс-инжиниринг, а питоновская обёртка maxapi-python находится в бета-состоянии. Мост работает круглосуточно на одной VPS с одним аккаунтом MAX, и любой необработанный обрыв связи может тихо съесть сообщения. Поэтому в проекте несколько точечных совместимостных прослоек к PyMax, каждая закрыта регрессионным тестом, а вся архитектура прогоняется в CI на фейковом MAX-бэкенде — сменяемость бэкенда проверена тестами, а не обещана на словах.

Что ещё есть под капотом:

• идемпотентная дедупликация: max_msg_id пишется в SQLite до отправки в Telegram, так что перезапуск в любой момент не наплодит дублей;
• устойчивая доставка — ретраи с экспоненциальной задержкой, очереди с lease/backoff/TTL, отложенное восстановление видео шестью попытками за 18 минут, вотчдог, который сообщит об офлайне MAX дольше 60 секунд;
• внешний вотчдог на второй VPS — он закрывает то, о чём сам мост доложить не может: остановленный контейнер, мёртвый хост и сломанные алерты;
• read-only статус-API: GET /healthz и защищённый токеном /status на loopback отдают коды проблем, глубину очередей и активный egress без текстов сообщений и названий чатов;
• метрики в формате Prometheus textfile, постоянная модель здоровья в JSON-файлах, команда /status для живого снимка;
• приватность по умолчанию: успешно доставленные тексты и медиа не хранятся, в SQLite лежат только маршрутные метаданные — исключение лишь для неотправленных текстовых сообщений, которые временно ставятся в очередь;
• реестр восстановления после миграции аккаунта: гибридные снапшоты сохранят привязку топиков, инвайты, админку и id собеседников, если потеряешь телефон или аккаунт.

Разворачивается всё в Docker Compose, продакшен-конфигурация описана для Hetzner Cloud: UFW, fail2ban, контейнер без root, доступ только по SSH-ключу. Внутри контейнера PID1 — supervisor, который держит контейнер живым и перезапускает воркер с backoff. Деплой, бэкапы, восстановление, бутстрап чистой VM и харденинг оформлены идемпотентными плейбуками Ansible, секреты и состояние остаются только на сервере. Трафик к API и CDN MAX при желании можно завернуть в аутентифицированный HTTP CONNECT-прокси, оставив Telegram напрямую.

Это open-source проект на GitHub, так что денег за него не просят — платить придётся только за VPS, на которой мост будет жить. Документация есть на английском и на русском, плюс в репозитории лежат архитектурный тур, ранбук и демо с подменой MAX-бэкенда. Учитывай главное: userbot неофициальный, API MAX не документирован, так что запуск требует технической руки и готовности следить за сервисом.