Не sender.
ОС для Telegram.

Когда мы стартовали TG:ON в 2023, первый вопрос инвесторов был: «почему desktop, а не cloud SaaS? Это же идёт против тренда». Ответ — не «мы ретрограды», а технически и продуктово осознанный выбор. Я разберу его здесь, потому что это объясняет большинство дальнейших решений в продукте.

Почему cloud-only не работает для Telegram operations

Массовый Telegram outreach предполагает долгоживущие MTProto сессии на многих аккаунтах. Каждая сессия привязана к auth-key + device fingerprint. Если эти данные лежат в cloud SaaS:

• Вендор имеет доступ к твоим аккаунтам — технически он может их use, ban, sell. Вопрос доверия, но риск реален.
• Vendor lock-in острее — миграция = экспорт всех session-keys и их re-import в другой сервис. Редко возможно clean.
• Compliance риски — в некоторых юрисдикциях хранение auth-keys третьей стороной = violation terms Telegram ToS.
• Центральная точка отказа — вендор упал = вся твоя ферма оффлайн.
• Shared infrastructure сигналы — если вендор использует те же IP-ranges для всех клиентов, и кто-то триггерит @SpamBot на одном ASN, группа клиентов страдает.

Что даёт desktop-бинарник

TG:ON — это один бинарный файл. Устанавливается как обычное приложение (.app / .exe / .deb). Внутри:

Через интернет уходит только:

1. Сами сообщения в Telegram (через MTProto, с твоими credentials)
2. API calls к LLM (если настроил) — идут напрямую от тебя к OpenAI/Anthropic/etc., не через нас
3. Обновления клиента (автоматические, подписанные нашим ключом)
4. Опциональные anonymous metrics (можно выключить)

Мы — не проходим через твой трафик. Не видим твои сообщения, не видим твои базы, не видим твоих клиентов. Модель: ты купил software, он работает у тебя.

5 модулей, общий state

Внутри бинарника:

• Parser daemon — индексация 4.8M+ каналов (client получает обновления), фильтры, экспорт
• Sender engine — MTProto client, Spintax, LLM proxy, rate-limiter
• Inviter worker — безопасный auto-invite с fingerprint checking
• Live Inbox CRM — единая inbox на всю ферму, теги, фильтры
• AI agents — Qualifier + Closer, подключаются к твоим LLM APIs

Все модули работают в одном процессе, разделяют SQLite-базу с лидами, используют общий rate-limiter и proxy-pool. Это означает:

• Лид, найденный парсером, сразу доступен для sender'а без export/import
• Ответы от лида автоматически появляются в Inbox без междупроцессной синхронизации
• AI-агент видит полный контекст (где нашли, что писали, что ответил) без API calls между сервисами
• Flood-limits централизованы — нельзя случайно перегрузить sender, пока parser тоже работает на том же аккаунте

Где desktop проигрывает cloud

Честно — локально-first архитектура не без минусов:

• Мобильные use-cases сложнее — ты не можешь «запустить рассылку с телефона». Компенсируем Telegram Mini App для мониторинга (видишь статус, читаешь входящие), но для запуска нужен десктоп.
• Команда из 10+ человек — collaborative workflow сложнее (нет shared database по умолчанию). Работает через sync между машинами, но это не так гладко, как в cloud CRM.
• 24/7 работа — твой компьютер должен быть включён. Альтернатива — запускать TG:ON на VPS (подробности в гайде), но это делаешь ты сам.

Почему «ОС», а не «sender»

Sender — это один инструмент, который делает одну вещь (отправляет сообщения). OS — это платформа, на которой можно строить разные рабочие процессы.

В TG:ON ты не ограничен «рассылками». Можно:

• Использовать только parser — собирать аудиторию для других целей (research, lead generation for another tool)
• Использовать только Inbox — единая CRM для управления фермой аккаунтов, без рассылок
• Комбинировать parser + inviter — building community channel, growing organic
• Использовать AI agents с ручной базой — отвечать на входящие от нерассылочных источников

Это не «5 продуктов, склеенные вместе» — это общая платформа, на которой ты выбираешь свои flow.