# Мост 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") или инкогнито.