icq/BRIDGE-TELEGRAM.md

Мост XMPP↔Telegram (Slidge/slidgram) — детали и задачи

Вспомогательный файл для STATUS.md; обновлено: 2026-08-29 Офлайн-доки: docs/slidgram/ (копия slidge.im)

Статус: ПОДКЛЮЧЁН (2026-08-29)

• Prosody: component_ports 5347 + Component "telegram.nixg.ru" с component_secret (⚠️ В Prosody 0.11 секрет задаётся ТОЛЬКО в секции Component через component_secret=; глобальная таблица component_secrets НЕ читается — была засада not-authorized).
• Образ: кастомный slidgram-proxy:latest = codeberg.org/slidge/slidgram:latest + патчи telegram.py/gateway.py (прокидывают SOCKS5 из env SLIDGRAM_PROXY в Pyrogram) + pysocks.
• docker-compose: сервис slidgram (icq-slidgram), env SLIDGE_JID/SECRET/SERVER/PORT, SLIDGRAM_PROXY=socks5://172.27.0.1:1080, том ./slidgram/data (uid 10000, иначе SQLite «unable to open database file»).
• ✅ Telegram App api_id/api_hash прописаны (2026-08-29): env SLIDGE__SLIDGRAM_API_ID и SLIDGE__SLIDGRAM_API_HASH (значения в docker-compose.yml; ⚠️ префикс плагина = SLIDGE__SLIDGRAM_ с ДВОЙНЫМ подчёркиванием — вычисляется в main.py как SLIDGE_ + _SLIDGRAM_; вариант SLIDGE_SLIDGRAM_* НЕ работает). Подтверждено эмуляцией set_conf: API_ID/API_HASH читаются. После правки env — пересоздать контейнер (docker compose up -d --force-recreate --no-deps slidgram), простой restart НЕ подхватывает новые env.
• Трафик Telegram → SOCKS5 172.27.0.1:1080 (SSH-туннель VPS01) — проверено: SOCKS5→MTProto DC1 OK.
• ✅ mod_privilege (XEP-0356): community-модуль → ./modules/mod_privilege.lua, включён в modules_enabled + privileged_entities в VirtualHost для telegram.nixg.ru (roster sync, legacy carbons). ⚠️ На Prosody 0.11.9 модуль из prosody-modules НЕ работает (зовёт API 0.12 module:send_iq). Стоит стаб-ACK (коммит 770c9fa): модуль отвечает ACK, не падает, но bookmarks/MDS через XEP-0356 не выполняются → слайдж шлёт приглашения в группы вручную (см. ниже). Полное решение — апгрейд Prosody на 0.12 (нативный XEP-0356), задача в STATUS.md.

Наблюдения после регистрации (2026-08-29)

• «Миллион запросов на подключение к чату» в Pidgin: слайдж шлёт gateway-приглашение на каждую группу (always_invite_when_adding_bookmarks: true + bookmarks не пишутся из-за сломанного mod_privilege → fallback на ручные приглашения). Не баг как таковой; уйдёт после апгрейда 0.12. Временно: always_invite_when_adding_bookmarks: false в preferences (SQLite user_account). ⚠️ Подтверждено в БД (2026-08-29 вечер): user_account.preferences = JSON {"always_invite_when_adding_bookmarks": true, ...}.
• Flood wait при первом старте: WARNING:slidgram.telegram:Flood in get_chat(...) sleep for N sec при синхронизации большого аккаунта (1602 контакта). Норма; кэш заполнится — паузы уйдут.
• Контакты «пропали» из ростера после рестарта: рostер на сервере цел (проверено, 1602). Клиент при переподключении сам запрашивает рostер; если в Pidgin пусто — Disable/Enable аккаунта. Проверять рostер сырым IQ (не через клиентский кэш slixmpp) — см. WALKTHROUGH §12.9.
• Каналов в рostере нет — это норма (2026-08-29 вечер): рostер = только личные контакты (1602, число@telegram.nixg.ru). Каналы/группы (91 канал + 40) — в таблице room БД моста, в XMPP показываются как bookmarks (сломаны). Папки TG слайдж не поддерживает. Подробности и обходной путь (Join вручную) — WALKTHROUGH §12.9.

Регистрация TG-аккаунта — ВЫПОЛНЕНА (2026-08-29)

• estorozhenko@nixg.ru → команда register (отправлена из Pidgin на адрес telegram.nixg.ru, способ B из WALKTHROUGH §12.3; Pidgin не даёт ad-hoc XEP-0050, только текст-сообщение).
• api_id/api_hash спрашивать не пришлось — уже в конфиге (SLIDGE__SLIDGRAM_API_ID/HASH).
• Проверено: Login success for estorozhenko@nixg.ru в логах, в БД user_account + контакты с vcard.
• Аватары контактов качаются через MTProto (не web.telegram.org) — в avatar появились записи.

ЗАДАЧА: аватары telegram-пользователей — загрузка таймаутит

• Симптом: аватары контактов/компонента не подтягиваются («загрузка аватаров/логотипа с web.telegram.org таймаутит»).
• Корень (по коду в контейнере icq-slidgram): HTTP-часть slidge НЕ ходит через SOCKS5 — slidge/core/gateway.py:399 создаёт aiohttp.ClientSession() без proxy=, и slidge/db/avatar.py (self.http.get(url)) качает URL-аватары напрямую; из РФ прямой доступ к web.telegram.org/photo-URL'ам заблокирован → таймаут. MTProto-часть (slidgram/telegram.py → Client(proxy=_proxy)) уже ходит через прокси и работает.
• Варианты решения (выбрать при реализации):
  1. Прокси в aiohttp-сессию: в gateway.py:399 aiohttp.ClientSession(proxy=...) (aiohttp — один прокси на сессию), либо ClientSession(trust_env=True) + env HTTP_PROXY/HTTPS_PROXY/ALL_PROXY. Для SOCKS5 в docker-сети — ALL_PROXY=socks5://172.27.0.1:1080
     • trust_env=True, но aiohttp SOCKS5 работает только через aiohttp-socks (доп. зависимость).
  2. Прогонять URL-аватары через nginx-прокси на bigbox (rewrite → туннель) — без правок кода.
  3. Аватары личных фото уже качаются через Pyrogram download_media() (MTProto, через SOCKS5) — убедиться, что эта ветка используется; прямая HTTP-загрузка нужна для URL-аватаров (web.telegram.org и т.п.).
• ⚠️ Обмен сообщениями, файлы и стикеры НЕ затрагиваются — это косметика (аватарки в ростере).

Известные мелочи

• Залипший localStorage браузера со старым JID admin@chat.nixg.ru → Converse шлёт host-unknown. Лечится: localStorage.removeItem("conversejs-session-jid") или инкогнито.