TonCalls: от сообщения до карточки контракта
Агрегатор TON-контрактов: карточки с графиком и источником, 900 подписчиков на пике и последующая продажа проекта.
TonCalls был моим проектом агрегации публикаций о TON-контрактах из Telegram-каналов. Вместо ручного просмотра нескольких источников я собирал сообщение, адрес контракта и контекст в одну карточку. Читатель получал исходную цитату, автора, график и дополнительные счётчики рядом.
Аудитория и итог проекта
На пике канал достиг 900 подписчиков. Он рос благодаря сарафанному радио: читатели рекомендовали его друг другу. Позже я продал TonCalls.
Как выглядел результат
В готовой публикации объединены превью, цитата источника, реакции, адрес и кнопки. Прежний канал закрыт, а код и пример публикации доступны на GitHub.
Путь сообщения
Чтением источников занимался userbot на Telethon. Отдельный бот публиковал оформленное сообщение с кнопками. Такое разделение сохраняло доступ к сообщениям источников и позволяло управлять представлением итоговой карточки.
1
2
3
4
5
6
7
Telegram-источники → Telethon → адрес контракта
↓
метаданные и контекст
↓
chart-proxy → составное превью
↓
публикация Telegram
В обработчике адрес извлекается из текста, затем проверяется контекст ссылки. Упоминания из обозревателей кошельков отсеиваются, чтобы адрес кошелька не превращался в карточку токена. Метаданные запрашиваются у DexScreener; отсутствие подходящей пары становится причиной пропустить публикацию.
Для получения сообщений предусмотрены события Telethon и дополнительная проверка истории. Она нужна для разрывов потока обновлений. Обработка исходного сообщения и подсчёт повторов одного контракта разделены: повторный приход одного поста не должен увеличивать его счётчик, а появление контракта в другом источнике добавляет контекст.
Карточка как отдельный сервис
HTTP-сервис chart-proxy отдавал HTML с Open Graph-разметкой и составлял PNG через Pillow. Telegram получал страницу превью и находил в ней изображение. В одной картинке объединялись график, медиа исходной публикации, автор и статистика.
У изображений были кэш в памяти и дисковый кэш. Это позволяло переиспользовать полученный график при повторных запросах превью. Получение данных и визуальная сборка находились в разных частях проекта, поэтому оформление карточки можно было менять отдельно от чтения сообщений.
Повторы и счётчики
SQLite использовалась для обработанных сообщений, истории упоминаний контрактов и кэшированных данных. Для истории контракта ключом служила комбинация адреса, канала и номера сообщения; повторная вставка игнорировалась.
Счётчики реакций вычислялись по недавним публикациям автора и обновлялись в фоне. Рядом с ними можно было показать число предыдущих упоминаний того же адреса. Это давало читателю сведения о происхождении сообщения и его повторяемости. Дополнительный короткий LLM-комментарий подключался опционально через Ollama или совместимый API.
Что оставил для повторного использования
Открытая версия включает два сервиса, пример публикации и конфигурации запуска. В ней можно изучить работу с событиями Telegram, SQLite, кэшированием и Open Graph-превью. Источники, аккаунт и параметры интеграций настраиваются отдельно для своего экземпляра.
Для меня основной результат — работающий путь от разрозненных сообщений до общего представления с сохранением источника.