«Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим.
Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день.
Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет.
Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно.
В какой-то момент я окончательно устал и собрал своё.
(Если вы к этому моменту уже переехали с Телеги на Макс ? – статья всё равно любопытная, читайте ради архитектуры.)
Называется Televizor. Логинишься через Telegram, выбираешь каналы, сообщения из них форвардятся в один чат-назначение внутри твоего же Telegram. Читаешь как RSS-ленту – хронологически, без алгоритмов, не выходя из привычного клиента.
Исходники (GPL-3)
Продакшн: televizor.click
Дальше – разбор архитектуры. Сразу честно: хардкорным бэкендером я себя не назову, писал с активной помощью моделей. От этого и 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. Пока приватный. Если интересно – напишите в комментах.
Комментарии (7)

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

kommunizm01 Автор
02.05.2026 18:52Хм, а подскажи название своего фида. Я почекаю в логах, что пошло не так. Можно в ЛС

msergein
02.05.2026 18:52Я для себя решил эту проблему конвертацией в RSS с помощью rsshub (конвертирует из веб версии для открытых каналов) и с помощью https://tg.i-c-a.su (конвертер который работает как полноценный тг клиент для каналов которые не открываются в веб). Плюс еще другие источники (habr например) тоже читаю через RSS. Все RSS источники собираются агрегатором freshrss - в итоге у меня один клиент для всего. Единственный минус, что нет мгновенного обновления, но в целом это не важно для блогов и новостей

kommunizm01 Автор
02.05.2026 18:52Дико плюсую! Тоже пользуюсь RSS. Написал себе простой парсер пабликов ВК в RSS ленту. Единственная беда с RSS - это визуальный контент и hosting-less парсинг визуального контента (картинки/видео). Например, большинство парсеров очень плохо справляются с VK, т.к. там стоят рейлы для кроулеров. В общем, когда хочется потупить в картинки, то я пользуюсь своим приложением, а когда хочется почитать текстоцентричные ленты (Reddit / интернет издательства / журналы), то смотрю RSS через приложение feeeed. Очень его, кстати, рекомендую!

msergein
02.05.2026 18:52Еще RSS сильно экономит время, вместо скроллинга полноценных постов как в телеге, в RSS клиентах можно настроить показывать только заголовок и пару предложений - в итоге лента пролистывается быстрее
С проблемами с медиа тоже сталкиваюсь, например у телеги адреса картинки со временем перестают грузиться, можно решить кэшированием, даже плагин готовый есть для freshrss, но что-то лень ) просто перехожу в телеге кликом из RSS клиента, если пост старый и картинки/видео не открываются. У меня андроид, на телефоне пользуюсь FeedMe, на бэке Freshrss как уже говорил
Мне в этой схеме нехватает только сквозного саммари по всем новым постам и автоперевода, может когда-нибудь добавлю
ze7
Если мне не изменяет память, стена, которую требовали вернуть- это было индивидуальное пространство на личной странице. То есть юзеры заходили друг к другу на страницы и читали стену, оставляли записи.
А потом он сделал кривой микроблог. Как раз то, о чём вы пишите - лента записей и все записи друзей в хронологии, появились лайки, комменты. Интерфейс был неудобный и поэтому родился этот мем: "Дуров, верни стену!" :)
kommunizm01 Автор
Истина! Пришлось залететь на кликбайт, чтобы просто прокоммуницировать свою мысль о том, что тот ВК, на котором я вырос – это было нечто уникальное в плане формирования разнообразного фида. Я в подростковом возрасте переехал из России в Европу, и понял, что в рунете потребление контента было абсолютно уникальным именно из-за ВК. С тех пор, как всё переехало в Телегу, мне не хватало именно приятного думскроллинга – такого, чтобы не оставалось неприятного осадка после в формате "на что я сейчас потратил 20 минут своей жизни?" Ниже в комментах кто-то упомянул RSS – сейчас я как раз потребляю весь контент через приложение feeeed и RSS ленты, а когда просто хочется потупить - то в тг через своё приложение. Плюс, не все мои любимые паблики из ВК переехали в ТГ по своим причинам.