xmpp-server-prosody/references/slidge-env-prefix-and-preset-api.md

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():

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)

  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:

  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.