# 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.