Initial commit: Hermes skill xmpp-server-prosody

2026-09-29 09:45:02 +00:00 · 2026-09-06 13:51:11 +00:00
commit 3da6c8709b
28 changed files with 2016 additions and 0 deletions
@@ -0,0 +1,64 @@
+# Slidgram: env prefix trap + preset api_id/api_hash (2026-08-29)
+
+Session-proven facts about configuring the Slidge/slidgram XMPP↔Telegram bridge
+via env vars. Companion to `slidge-registration-and-avatar-gap.md` and
+`slidge-telegram-bridge-nixg.md`.
+
+## The SLIDGE__SLIDGRAM_ prefix (DOUBLE underscore)
+
+Slidge plugin config env vars are NOT `SLIDGE_SLIDGRAM_*` — the prefix is
+**`SLIDGE__SLIDGRAM_`** (double underscore). Derived in `slidge/main.py:configure()`:
+
+```python
+ConfigModule.ENV_VAR_PREFIX = "SLIDGE_"          # base (slidge.util.conf)
+ConfigModule.ENV_VAR_PREFIX += f"_{config.LEGACY_MODULE.split('.')[-1].upper()}_"
+# LEGACY_MODULE = 'slidgram' → "_SLIDGRAM_"
+# result: "SLIDGE__SLIDGRAM_"
+```
+
+So for a plugin config option `API_ID` (defined in `slidgram/config.py`) the
+env var is `SLIDGE__SLIDGRAM_API_ID`. Setting the single-underscore
+`SLIDGE_SLIDGRAM_API_ID` is silently ignored → `config.API_ID` stays `None` →
+the registration form falls back to asking every user for api_id/api_hash.
+
+## docker-compose (preset app credentials once)
+
+```yaml
+  slidgram:
+    environment:
+      - SLIDGE_JID=telegram.nixg.ru
+      # ...
+      - SLIDGE__SLIDGRAM_API_ID=<api_id from my.telegram.org/apps>
+      - SLIDGE__SLIDGRAM_API_HASH=<api_hash>
+```
+
+## Applying env changes — force-recreate, NOT restart
+
+- `docker compose restart` does **NOT** apply new/changed `environment:` entries
+  — the container keeps the old env (verified: env vars absent after restart).
+- Must recreate the container:
+  `docker compose up -d --force-recreate --no-deps slidgram`
+  (`--no-deps` avoids touching prosody). Compose v2 warns about the obsolete
+  `version:` attribute — harmless.
+
+## Verifying the config was read
+
+- The slidge entrypoint (`slidgram` console script → `slidgram:main`) runs
+  `ConfigModule(plugin_config).set_conf()` which is what reads env into
+  `slidgram.config`. A throwaway `docker exec ... python -c "from slidgram
+  import config; print(config.API_ID)"` shows `None` — this is EXPECTED, not a
+  failure (set_conf never ran in that throwaway process).
+- Reliable check — emulate the entrypoint:
+  ```python
+  from slidgram import config as plugin_config
+  from slidge.util.conf import ConfigModule
+  ConfigModule.ENV_VAR_PREFIX = 'SLIDGE__SLIDGRAM_'
+  ConfigModule(plugin_config).set_conf([])
+  print(plugin_config.API_ID, plugin_config.API_HASH)
+  ```
+- Or trust the live logs: after a clean start, `docker logs icq-slidgram |
+  grep -iE 'Slidge has successfully started'`. The recurring
+  `ConnectionTimeoutError ... web.telegram.org/img/logo_share.png` avatar
+  timeout in those logs is the KNOWN HTTP-gap (slidge's aiohttp client is not
+  SOCKS5-proxied) and is NOT a sign of breakage — it does not block
+  registration or messaging.