# Мост 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).

## Регистрация 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") или инкогнито.