[OMEGA-419] Route Telegram file downloads through the gateway proxy

[surafelfikru]

Telegram serves API methods from /bot<token>/ but uploaded files from /file/bot<token>/, and the proxy only routed the first, so every media download 404'd behind the gateway while text messages kept working — which reads as broken media handling rather than a missing route. This adds the file route next to the existing one, so photos, documents and voice notes resolve:

location /telegram-file/ {
    rewrite ^/telegram-file/(.*)$ /file/bot${TG_BOT_TOKEN}/$1 break;
    proxy_pass https://api.telegram.org;
}

nginx.sh needs no change; it builds its envsubst list by grepping ${VAR} out of the template, so TG_BOT_TOKEN is already picked up from the existing /telegram/ route. Verified by rendering the template through the same grep-and-envsubst that nginx.sh runs: the token expands and nginx's own $1 capture group is left alone.

One note for later. This route belongs to a plugin, but it sits in core, like the Slack and Mattermost ones. A plugin cannot add a route on its own today. The template has no include line, and the Dockerfile copies proxy/* flat, so a file shipped by a plugin is copied but never read. We could change this with an include inside the server block and a Dockerfile line that collects plugins/*/proxy/*.conf. Two rules would make it safe. First, collect the files at build time, not with a glob at runtime. Then the list of routes is fixed inside the image, and the agent cannot add one while the container is running. Second, run envsubst on each plugin file with only the variables that the file itself declares. Right now nginx.sh greps the variable names out of the template and gives them to envsubst. If we did the same for plugin files, a plugin could write ${ANTHROPIC_API_KEY} inside its own route and read the real key. With a per-file list, a name that is not declared stays as plain text, nginx does not know it, and the container fails to start instead of leaking the key:

# plugins/telegram/proxy/telegram-file.conf
# vars: TG_BOT_TOKEN
location /telegram-file/ { ... }

[surafelfikru]

Let me know if the plugin extensions for the nginx configuration is the correct approach and i will start working on it.

[vsbogd]

Looks good to me, thanks!

Let me know if the plugin extensions for the nginx configuration is the correct approach and i will start working on it.

There is a suggestion to migrate to use LiteLLM as a proxy for keeping authentication secrets. From this perspective I think it is better to implement it for the LiteLLM after it is introduced.

[vsbogd]

From this perspective I think it is better to implement it for the LiteLLM after it is introduced.

Oh, I forgot that this is about communication plugins and they cannot be proxied by LiteLLM so Nginx or other separate solution will still be needed. Thus make sense to introduce it.

Getting the Nginx configuration from the plugins on agent start looks like a good start. It would be cool if we could change configuration dynamically when plugin is loaded or unloaded instead of doing this once on the start. But it seems it make things less safe and more complex. I would think about it for a day and return to you if you don't mind.

[surafelfikru]

Sure, take your time. dynamic loading seems interesting so i will keep it on the back of my head.