docs: задача по аватарам TG в мосте (HTTP не через SOCKS5) + инструкция регистрации slidgram (WALKTHROUGH 12)

STATUS.md

@@ -1,6 +1,6 @@
 # ICQ XMPP — ТЕКУЩИЙ СТАТУС И ПЛАН (точка входа для новой сессии)
 
-> Обновлено: 2026-08-29 · Сессия: bigbox (/opt/icq)
+> Обновлено: 2026-08-29 (вечер) · Сессия: bigbox (/opt/icq)
 > ⚠️ МИГРАЦИЯ НА nixg.ru (2026-08-28): JID юзеров теперь `user@nixg.ru`, веб-клиент остаётся на chat.nixg.ru, WS → wss://xmpp.nixg.ru. См. MIGRATION.md.
 > ✅ Документация полная и актуальная: [WALKTHROUGH.md](WALKTHROUGH.md) (все этапы, команды, засады, TLS, HTTP Upload) · [PRD.md](PRD.md) (требования/архитектура) · [MIGRATION.md](MIGRATION.md) (переезд).
 
@@ -162,6 +162,26 @@ chromium --headless --no-sandbox --disable-gpu --enable-logging=stderr --virtual
       - ✅ **Аудит XEP-функций** (2026-08-29) → **XEP-AUDIT.md**: MUC/PubSub/HTTP Upload/MAM/Carbons/PEP ✅;
         OMEMO/WebRTC — клиент-сайд (норма для 0.11); Bookmarks — через PEP; mod_pubsub включён в modules_enabled.
       - ОЖИДАЕТ: регистрацию TG-аккаунта (admin@nixg.ru → команда register на telegram.nixg.ru) + api_id/api_hash.
+      - 📖 **Регистрация в slidgram — ПОШАГОВАЯ ИНСТРУКЦИЯ:** см. **WALKTHROUGH.md → раздел «Slidgram: регистрация telegram-аккаунта»** (нужен api_id/api_hash с my.telegram.org/apps; команда `register` с telegram.nixg.ru; код → на ваш TG; 2FA → пароль). Процесс общается с Telegram ТОЛЬКО через MTProto (SOCKS5-туннель) — HTTP my.telegram.org для получения api_id/hash придётся открыть в обычном браузере на вашей машине.
+- [ ] **Аватары telegram-пользователей в мосте: загрузка таймаутит (2026-08-29)** — слабое место, требует починки после регистрации:
+      - Симптом: аватары контактов/компонента не подтягиваются; в прошлой сессии зафиксировано
+        «загрузка аватаров/логотипа с web.telegram.org таймаутит».
+      - Корень (найдено по коду в контейнере icq-slidgram): HTTP-часть slidge НЕ ходит через SOCKS5:
+        `slidge/core/gateway.py:399` создаёт `aiohttp.ClientSession()` без `proxy=`, и
+        `slidge/db/avatar.py:112` (`self.http.get(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` (aiohttp читает их при trust_env). Если в docker-сети
+            нужен хостовый SOCKS5 — задать `ALL_PROXY=socks5://172.27.0.1:1080` и `trust_env=True`;
+            но aiohttp SOCKS5 поддерживается только через aiohttp-socks (доп. зависимость).
+        (2) Пройти все URL-аватары через nginx-прокси на bigbox (rewrite → туннель) — без правок кода;
+        (3) в slidgram/telegram.py аватары уже качаются через Pyrogram `download_media()` (MTProto,
+            через наш SOCKS5). Убедиться, что часть аватаров (личные фото юзеров этой веткой) идёт
+            именно так; прямая HTTP-загрузка нужна для URL-аватаров (web.telegram.org и т.п.).
+      - ⚠️ Обмен сообщениями, файлы и стикеры НЕ затрагиваются — это косметика (аватарки в ростере).
 - [ ] Мосты mautrix (WhatsApp) — Этап 4; нужен external component (mod_component). [Telegram-мост уже на Slidge]
 - [ ] Push-уведомления (APNs/FCM) — ОТЛОЖЕН (нет особой потребности; см. WALKTHROUGH раздел 10.4 «Варианты»).
       Пробовал (2026-08-29): mod_unified_push из apt-prosody-modules НЕ подходит — требует util.jwt (API 0.12), а контейнер на 0.11.9.