«Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим.

Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день.

Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет.

Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно.

В какой-то момент я окончательно устал и собрал своё.

(Если вы к этому моменту уже переехали с Телеги на Макс ? – статья всё равно любопытная, читайте ради архитектуры.)

Называется Televizor. Логинишься через Telegram, выбираешь каналы, сообщения из них форвардятся в один чат-назначение внутри твоего же Telegram. Читаешь как RSS-ленту – хронологически, без алгоритмов, не выходя из привычного клиента.

Дальше – разбор архитектуры. Сразу честно: хардкорным бэкендером я себя не назову, писал с активной помощью моделей. От этого и open-source.


Telethon vs Bot API: выбор, который определил всё остальное

Bot API – это HTTP-обёртка поверх MTProto от Telegram. Удобная, хорошо задокументированная, и принципиально бесполезная для задачи агрегации. Проблема не в качестве, а в модели авторизации: бот существует отдельно от пользователя и видит только те каналы, в которых он явно назначен администратором. То есть чтобы читать публичный новостной канал через бота, нужно зайти в настройки этого канала и добавить туда постороннего бота с правами. Никто на это не пойдёт.

Telethon решает это иначе: он подключается от имени самого пользователя через MTProto, тот же протокол, что использует официальный Telegram Desktop и любой третьесторонний клиент – Unigram, Plus Messenger, Nekogram. Это означает полный доступ ко всем каналам, на которые подписан аккаунт, без каких-либо административных договорённостей.

Компромисс – серая зона ToS. Telegram прямо не запрещает пользовательские MTProto-клиенты, иначе убил бы весь свой третьесторонний экосистем одним решением. Но автоматизация, которая по поведению похожа на спам или массовый сбор данных, – риск отзыва API ключей или бана аккаунта. Снижаю это задержкой форварда в 15 секунд, скользящим rate limiting через Redis, обработкой SessionRevokedError с немедленной остановкой воркера. На собственном аккаунте – ноль банов за месяцы работы.


Event-driven против polling: почему это важно

Когда читаешь про Telethon, первый инстинкт – написать цикл, который каждые N секунд спрашивает у каналов новые сообщения. Это polling, и у него два принципиальных минуса для этой задачи.

Во-первых, задержка. При polling сообщение появится у пользователя в среднем через половину интервала – то есть если интервал 30 секунд, медианная задержка 15 секунд. Для новостных каналов это ещё терпимо, для торговых сигналов – уже нет.

Во-вторых, масштабирование. Polling N каналов для M пользователей – это N×M запросов каждый цикл. При росте числа пользователей это становится дорогим и быстро упирается в rate limits.

Telethon поддерживает event-driven модель через events.NewMessage – постоянное соединение, которое получает обновления в момент их появления. Один persistent connection на аккаунт вместо бесконечного цикла запросов. Задержка форварда определяется только намеренно добавленной паузой в 15 секунд, а не интервалом polling.


Как устроен форвард и зачем дебаунс на альбомах

Сообщение приходит через events.NewMessage, воркер смотрит в source_to_feeds – это словарь, который маппит ID канала-источника на список конфигов фидов, подписанных на этот канал. Если канал есть в словаре, сообщение проходит через фильтры и уходит форвардом в destination через forward_messages. Сообщение нигде не сохраняется – только транзитом через память.

Отдельная головная боль – альбомы. Telegram шлёт пачку фото или видео в одном посте как несколько независимых сообщений с общим grouped_id. Если форвардить их по одному, на приёмнике альбом разваливается на отдельные медиафайлы без подписи. Поэтому: двухсекундный дебаунс, который собирает все части альбома с одним grouped_id и форвардит их единым вызовом forward_messages. Таймер сбрасывается при каждой новой части. На практике части приходят в пределах 0.5–1.5 секунды, запас достаточный.


Rate limiting: скользящие окна без cleanup-job

Вся антифлуд-логика сидит в Redis. Для каждого пользователя и каждого типа действия – два ключа: почасовой счётчик и суточный. Ключи автоматически истекают через TTL, отдельный cleanup-job не нужен.

Скользящее окно реализовано через деление unix timestamp на длину периода: now // 3600 даёт текущий час как целое число, now // 86400 – текущие сутки. При смене часа старый ключ перестаёт инкрементироваться и умирает по TTL. Это не точное скользящее окно (это tumbling window), но для rate limiting с такими периодами достаточно.


Потенциальные угрозы

Session string – это функциональный эквивалент токена авторизации Telegram-аккаунта. Самое чувствительное место в архитектуре, и я описываю его прямым текстом, а не прячу в мелкий шрифт.

Хранится в базе: номер телефона, Telegram ID, Telethon session string, конфиги фидов, тариф и срок подписки. Не хранится ничего из содержания: ни сообщения, ни история чатов, ни контакты, ни медиа, ни аналитика использования.

Если база утечёт – атакующий получит session strings и сможет подключиться к Telegram от имени пользователей. Контрмера: сессию можно убить в любой момент через настройки Telegram, это немедленно деактивирует строку. Televizor не запрашивает 2FA-пароль, поэтому сменить пароль или удалить аккаунт через чужую сессию нельзя.

Session strings в базе хранятся зашифрованными через Fernet (AES-128-CBC + HMAC-SHA256). Шифрование включается через SESSION_ENCRYPTION_KEY в переменных окружения – если ключ установлен, в базу уходит шифротекст, без ключа – plaintext (обратная совместимость для старых данных). При self-hosting: сгенерируйте ключ, пропишите в .env, новые сессии сразу пойдут зашифрованными.

Если модель угроз не устраивает – self-host на Docker Compose. Тогда сессия вообще не покидает вашу машину.


Self-hosting

Docker Compose, четыре контейнера: frontend, backend, postgres, redis. В покое – около 180 МБ RAM, под нагрузкой – до 350 МБ. TELEGRAM_API_ID и TELEGRAM_API_HASH нужно получить на my.telegram.org, всё остальное в .env.example. Для прода – reverse proxy с TLS. Важно бэкапить postgres_data: потеря базы означает потерю session strings и повторный логин для всех пользователей.


Что в планах

Шардинг воркеров на несколько процессов – пока не нужен, узкое место не CPU воркера, а FloodWait на уровне Telegram-аккаунта. Один процесс спокойно тянет сотни пользователей. Тема станет актуальной после 1000+ активных аккаунтов. Дедупликация сообщений при пересечении фидов – требует таблицы fingerprint'ов и записи на каждую доставку, нагрузка не оправдана пока никто не жалуется.

PR welcome. Особенно по тестам, шардингу и шифрованию сессий.


P.S. Если скучаете по нишевым VK-сообществам, которые так и не переехали в Telegram – у меня есть маленький VK-to-RSS конвертер, читаю его через feeeed. Пока приватный. Если интересно – напишите в комментах.

Комментарии (2)


  1. ze7
    02.05.2026 18:52

    Если мне не изменяет память, стена, которую требовали вернуть- это было индивидуальное пространство на личной странице. То есть юзеры заходили друг к другу на страницы и читали стену, оставляли записи.
    А потом он сделал кривой микроблог. Как раз то, о чём вы пишите - лента записей и все записи друзей в хронологии, появились лайки, комменты. Интерфейс был неудобный и поэтому родился этот мем: "Дуров, верни стену!" :)


  1. foreva
    02.05.2026 18:52

    Не работает: канал создался, источники добавлены, лента активна — и ничего не происходит.