Интеграция Telegram в Kontinuum — исследование

Долговечный исследовательский документ. Сводит воедино техническую, правовую и продуктовую ветки исследования (мейлстоун M14, issue #77). Это проектное решение и три открытые развилки, а не план реализации: план живёт в GitLab-issues, документ хранит метод, инварианты и обоснования.

1. Резюме и рекомендация

Рекомендуемый путь — Режим A (периодический read-only импорт), выполняемый только на устройстве пользователя, в контуре Armenia-IP, без секретных чатов. Ценность интеграции — не вьюер мессенджера, а агент НАД импортированным корпусом: суммаризация переписок, извлечение задач, семантический поиск, мониторинг. Telegram остаётся отдельным приложением; мы забираем то, чем пользователь уже владеет, и даём над этим интеллект.

Перед армингом любой реализации основателю нужно закрыть три развилки:

• Источник данных — #82: официальный JSON-экспорт Telegram Desktop (рекомендация продукта/CTO) против live-API через grammers.
• Идентичность продукта (soul) — #83: остаёмся ли мы навсегда в Режиме A (импорт), или Режим B (живой мост) — будущая стратегическая ставка.
• Правовой гейт — #84: CLO дал GO-с-условиями только для Режима A on-device/Armenia-IP; всё за пределами этой зелёной полосы требует оплаченных консультантов.

CLO-вердикт коротко: GO-с-условиями для Режима A on-device/Armenia-IP/без секретных чатов; NO-GO для РФ-контура, для облака/узла и для Режимов B/C без письменных заключений консультантов.

2. Каркас режимов A / B / C

Три уровня глубины интеграции. Они различаются не «фичами», а тем, сколько спины продукта (local-first, суверенитет, отсутствие центральной зависимости) приходится заложить.

Режим	Что это	Сложность	Риск	Фит с суверенитетом
A — импорт (read-only)	Периодический односторонний перенос истории Telegram в наши E2E-Spaces	Низкая–средняя	Низкий (особенно на JSON-экспорте)	Высокий — приноси свою историю, агенты её обслуживают
B — живой мост (read+send)	Двусторонний: агент читает и действует в чатах в реальном времени	Высокая	Высокий — постоянная центральная зависимость от серверов Telegram, привязка аккаунта, риск бана, расширенная legal-поверхность	Средний/спорный — вводит внешнюю зависимость, рискует превратить нас в «ещё один мульти-мессенджер»
C — встроенный клиент	Полноценный Telegram-клиент внутри Kontinuum	Очень высокая	Очень высокий — прямая конкуренция с самим Telegram	Низкий — почти наверняка нет

Режим A — единственный, что целиком укладывается в зелёную правовую полосу и не размывает идентичность продукта. Режим B — ценностная развилка (см. §8, #83), а не просто «фича». Режим C в обозримом горизонте отвергается.

3. Техническая часть

3.1 grammers против telethon

Исходный бриф называл оба клиента. Технический вывод однозначен под наш Rust-first стек: grammers — нативный Rust-крейт, который встаёт в рабочее пространство без сайдкара и IPC. telethon тянет за собой Python-сайдкар, а CPython на Android — это тяжёлая и хрупкая обвязка.

Критерий	grammers (Rust)	telethon (Python)	Вердикт
Язык / фит	Нативный Rust-крейт в нашем workspace, без сайдкара	Python → отдельный сайдкар + IPC; CPython-на-Android тяжело	grammers — попадает в стек
Зрелость	0.x, без аудита	Зрелый, но GitHub-репозиторий архивирован 21.02.2026; v2 в alpha	Ничья со звёздочкой
Покрытие MTProto	Полное (в т.ч. через raw tl::functions)	Полное	Паритет
Авторизация	Телефон+код / 2FA / QR	Телефон+код / 2FA / QR	Паритет
Хранение сессии	Трейт Session → наш адаптер в Stronghold	Файл .session (SQLite)	grammers — чище ложится в наш keystore
Live-обновления	getDifference	getDifference	Паритет
Скачивание медиа	Чанками	Чанками	Паритет
Крипто-аудит	Нет	Нет	Обоюдный минус
Сборка под Android	В принципе да — НЕ проверено	CPython — тяжело	grammers, но за гейтом spike

Рекомендация: grammers — при условии, что выбран live-API путь (см. §8, #82). Если же источником выбран официальный JSON-экспорт, MTProto-клиент вообще не нужен.

3.2 Что доступно и что недостижимо через user-MTProto

User-MTProto (от лица пользователя, а не бота) даёт практически полный доступ к тому, что видит сам пользователь: личные диалоги, группы, супергруппы, каналы, история, медиа, контакты. Секретные чаты недостижимы по дизайну — это device-to-device E2E поверх MTProto, ключи живут только на конкретных устройствах и через API не отдаются. Это удачно: секретные чаты автоматически выпадают из любой интеграции, что снимает целый класс правовых и этических вопросов.

3.3 Архитектура интеграции

Жёсткие инварименты, которые держат интеграцию внутри спины продукта:

• Клиент / импортёр работает ТОЛЬКО на устройстве пользователя. Никогда — на узле или сервере. Это и техническое решение, и правовой водораздел (см. §4).
• Сессия и секреты (api_id/api_hash, токен сессии) — в Stronghold. Для grammers это реализуется через адаптер трейта Session поверх нашего защищённого хранилища.
• Медиа идут через существующий механизм контента бесплатно получая E2E-at-rest и crypto-erasure. Импортёр кладёт байты через import_files/import_bytes в CAS (адресация по blake3), затем seal_blob — и медиа автоматически зашифрованы на покое и подлежат криптостиранию при удалении владельцем. Никакого отдельного крипто-кода писать не нужно.
• По запросу, инкрементально, с бэк-оффом. Никакого сплошного фонового экспорта — это путь к флуд-лимитам и бану аккаунта.

Гейт live-API: Android-NDK spike

Перед любой live-API реализацией нужен спайк #80: собирается ли grammers под наш Android-NDK-таргет. Крейт нативный и в принципе кросс-компилируется, но не проверено, что его зависимости по TLS/tokio/крипто встают в нашу обвязку (aws-lc-sys / bindgen-sysroot). Если сборка не даётся малой кровью — нативная выгода Rust испаряется, и сайдкар telethon (худший вариант) снова на столе. Спайк не нужен, если выбран путь официального JSON-экспорта.

4. Правовая часть (CLO)

4.1 Главный риск — данные третьих лиц

Любой чат содержит персональные данные других участников, которые не давали нам согласия. Это центральный риск всей интеграции, и он целиком определяется тем, где данные хранятся:

• On-device. Пользователь хранит собственную переписку на собственном устройстве. Это покрыто бытовым исключением — household exemption GDPR (обработка в личных/семейных целях) и аналогичной нормой 152-ФЗ (ст. 1, обработка ПДн физлицом для личных нужд). Мы — не оператор.
• В наше облако / на узел. Бытовое исключение схлопывается. Как только чужие ПДн оказываются в нашей инфраструктуре, мы становимся оператором ПДн третьих лиц без правового основания, и в РФ-контуре подключается требование локализации 152-ФЗ. Это качественный скачок риска, а не количественный.

Именно поэтому инвариант «только на устройстве» — не техническая прихоть, а граница правовой допустимости.

РФ-контур — NO-GO

С февраля–марта 2026 Telegram под блокировкой РКН именно по мотиву незащищённости персональных данных. Любая наша интеграция в РФ-контуре токсична: помимо общего риска оператора чужих ПДн добавляется риск трактовки как содействие обходу блокировки. РФ-контур для Telegram-интеграции — NO-GO.

4.2 Что МОЖНО и что НЕЛЬЗЯ заявлять

Можно заявлять	Нельзя заявлять
«Импортируйте свою историю Telegram на своё устройство»	«Подключите Telegram к облаку Kontinuum»
«Данные остаются у вас, обработка — локальная»	«Мы храним/синхронизируем ваши чаты Telegram»
«Агент работает над вашим личным архивом»	«Используйте Kontinuum как Telegram-клиент»
«Read-only импорт, секретные чаты не затрагиваются»	Любые формулировки про РФ-контур
«Вы — экспортёр собственных данных» (для JSON-пути)	«Мы оператор / мы обрабатываем данные ваших собеседников»

4.3 Чек-лист условий GO

Реализация допустима, только если выполнены все пункты:

• [x] Режим A (read-only импорт) — не B/C
• [x] Обработка и хранение только на устройстве пользователя
• [x] Контур Armenia-IP (не РФ)
• [x] Секретные чаты исключены (обеспечено технически)
• [x] CLO-ревью копирайта/формулировок перед публичными заявлениями
• [ ] Для любого выхода за on-device / Armenia-IP — оплаченный РФ-консультант (вопросы: статус оператора при payload-blind E2E; действие household-исключения при хранении у нас; локализация E2E-блоба; риск содействия обходу блокировки)
• [ ] Перед облаком/узлом — оплаченный GDPR-консультант

Первые пять пунктов — это зелёная полоса MVP. Последние два — гейт основателя (#84) для любого расширения.

5. Продуктовая часть

5.1 Маппинг сущностей Telegram → наши

Модель Kontinuum: Space ⊃ Collection(Kind) ⊃ Item. Telegram-сущности ложатся на неё так (с честным указанием натяжек):

Сущность Telegram	Наша сущность	Натяжки / примечания
User / Contact	Item в Base-коллекции «Люди»	—
Saved Messages	Space (1 участник) ⊃ Chat-коллекция	Самый ценный первый таргет
Личный диалог	Space, где реальный член — только ты; собеседник = строковый автор	Собеседник не член: не фабрикуем чужие device-ops
Группа / супергруппа	Space ⊃ Chat-коллекция; участники → Base «Люди»	Участники = контент, не члены
Channel (broadcast)	Space ⊃ Chat-коллекция (read-only по природе)	broadcast/group — флаг, не отдельный kind
Forum-topics	Несколько Chat-коллекций в одном Space (по топику)	—
Message (текст)	Item, payload = ChatMessagePayload	Фикс-форма, не FieldValues
Message (сервисное)	Item с флагом service	—
Media (фото/видео/документ/аудио)	Item-сообщение + блоб в File/Media-коллекции (content-store), ссылка по ContentId	—
voice / video-note / sticker	Медиа + флаг подтипа	На MVP — обычный файл; sticker дропнуть
Poll	Снапшот как текст	Полный Poll-тип позже
geo / contact / webpage-preview	Поля в payload	preview ценен агенту; geo/contact — низкий приоритет
Reactions	Массив в payload сообщения	Данные на MVP, UI позже (интерактив — это Режим B)
Replies / threads	reply_to_item_id в payload	Данные на MVP, тред-рендер позже
Pinned	Флаг pinned	—
Drafts	Не импортируем	read-only
Dialog-folders	На MVP — плоско	У нас нет «папок Spaces»

Визуально это же:

5.2 Что построить и что «скопипастить»

• CollectionKind::Chat — форсинг-фактор (#79). Сегодня ObjectKind::Chat — пустой вариант enum (kontinuum-content/src/lib.rs), ноль кода. Нужно построить настоящий Chat как app-layer payload-тип на существующем content-plane: новый ChatMessagePayload (sender / ts / text / reply_to_item_id? / kind / media_ref? / pinned / reactions? / preview? / edited?) рядом с ItemPayload/ FilePayload, golden-hash, FE-проекция timeline (read-only, по ts). ZERO-core: нода трактует payload как opaque, Chat — новый payload, а не новая ось. Если тянет к ноде/wire/fold — это сигнал Режима B/C, стоп. Строить один раз generically: потребители — (1) TG-импорт, (2) нативный DM (2-членный Space, хвост G3 в M1). Не строить дважды. И не раздувать в движок мессенджинга (typing / read-receipts / real-time — это B/C).
• Импортёр Режима A (#81): парсер источника → маппинг по таблице → авторинг локальных ContentOps + медиа в content-store.
• Контакты → Base «Люди»: импортированные участники как записи-Item.

Инвариант: импортированные участники чата — контент, а не члены Space. Мы не фабрикуем device-ops за чужих людей; членство остаётся honest surface.

6. UI / UX

6.1 Поток мастера-импортёра

Линейный осознанный мастер:

1. Точка входа — действие «Импортировать из Telegram» (например, при создании Space или из меню коллекций).
2. Откуда — выбор источника (зависит от развилки #82: загрузить JSON-экспорт Telegram Desktop или авторизоваться через live-API).
3. Что — выбор диалогов/каналов для импорта (по умолчанию — Saved Messages как самый ценный первый таргет).
4. Куда — в новый или существующий Space.
5. Прогресс — инкрементальный, с бэк-оффом, видимый и прерываемый.
6. Результат — сводка: сколько сообщений/медиа/контактов импортировано.

6.2 Архив-вид (timeline)

Импортированный чат показывается как read-only timeline, упорядоченный по времени. Поля ввода нет — это honest surface: Режим A не умеет отправлять, и UI не должен это симулировать. Отправка появилась бы только в Режиме B.

6.3 Агентский слой — ядро ценности

Главная ценность не во вьюере, а в агенте над корпусом. На импортированном архиве агент даёт:

• суммаризацию переписок и каналов;
• извлечение задач и обязательств;
• семантический поиск по всей истории;
• мониторинг (дайджесты, отслеживание тем).

Это напрямую обслуживает use-cases #3 / #4 / #8 (агент над личным корпусом). Именно этот слой превращает «импорт чатов» в «суверенный дом, где агенты работают над тем, чем ты уже владеешь».

7. MVP-срез

Минимальный честный срез:

• Режим A (read-only импорт), on-device, Armenia-IP, без секретных чатов.
• Источник — по решению развилки #82 (рекомендация — официальный JSON-экспорт).
• CollectionKind::Chat + ChatMessagePayload + read-only timeline.
• Один агентский сценарий (например, суммаризация Saved Messages или семантический поиск по импортированному архиву).

Из MVP исключены: drafts, stickers, Poll-как-полноценный-тип, интерактивные reactions, тред-рендер, dialog-folders.

Поток данных при импорте — целиком на устройстве:

8. Развилки основателю

• #82 — Источник данных. Официальный JSON-экспорт Telegram Desktop (пользователь сам осознанно выгружает свои данные → чисто под суверенитет, нет api_id/сессии/риска бана, легче для CLO) против live-API через grammers (инкрементально, ближе к агенту-в-реальном-времени, но требует сессии в Stronghold, несёт риск бана и Android-build-spike). Lean CTO/PM: JSON-экспорт на MVP, grammers — позже, если нужен live. Решение за основателем, т.к. он явно назвал grammers.
• #83 — Soul: Режим B/C. Это не фича, а вопрос, чем является Kontinuum: про контент, которым ты уже владеешь (A), или агент должен жить и действовать в твоих текущих внешних коммуникациях (B), приняв опциональную центральную зависимость? Lean PM: Опция 1 (только A) для MVP; Опция 2 (A сейчас, B позже как Tier-2) — только если основатель делает стратегическую ставку на агентов-действующих-в-реальном-времени.
• #84 — Legal-гейт. CLO: GO-с-условиями только для Режима A on-device/Armenia-IP. Для любого выхода за эту полосу — оплаченные консультанты (РФ-консультант для расширения за Armenia-IP; GDPR-консультант перед облаком/узлом). До письменных заключений реализация ограничена зелёной полосой.

9. Источники

Ключевые ссылки по теме (см. также issue #77):

• Telegram API — Terms of Service: https://core.telegram.org/api/terms
• Telegram API — авторизация пользователя (MTProto): https://core.telegram.org/api
• grammers (Rust MTProto-клиент): https://github.com/Lonami/grammers
• telethon (Python MTProto-клиент): https://github.com/LonamiWebs/Telethon
• GDPR — household exemption (Art. 2(2)(c), обработка в личных целях): https://gdpr-info.eu/art-2-gdpr/
• 152-ФЗ «О персональных данных», ст. 1 (бытовое исключение) и ст. 18 (локализация): http://www.consultant.ru/document/cons_doc_LAW_61801/

⚠ Точные первоисточники по блокировке Telegram РКН (фев–мар 2026, мотив — незащищённость ПДн) на момент написания фиксируются в issue #77; при наличии официальных публикаций РКН/Минцифры их следует добавить сюда.