This is off-topic, but I was kind of surprised to see this page written by Claude. I guess I shouldn't really be surprised, but I somehow didn't expect it.
Same. I used to use telegram for everything and then stopped after I realised it wasn’t really and to end encrypted. The bots were super useful. I used to have one I could ask different bus times for. Was so much better than the app the local bus company had made.
I use a signal api on a daily basis for all my agentic chatting and notifications about energy prices and server downtime notification.
Setup was quick enough but it needs a real phone number once during setup which is kind of a hassle. still better than using telegram which has no encryption for the bot backend so the devs can read everything you write
> Each invocation runs in a lightweight V8 isolate, close to Telegram's own systems, so calls to the Bot API and your database are quick and reliable.
Telegram’s servers are distributed worldwide. I understand that the calls to the Bot API may be quick because the serverless code would be propagated to the edge, but how does it handle an SQLite DB? Is that also replicated to guarantee quick access from anywhere?
Good lord. This reeks of LLM... why should I use your product when you can't be bothered to have a human write it? Why should I trust it to work correctly or have been decently tested, neither of which is a given when having an AI vibe-code it?
And why is it one huge single page of word salad instead of self-contained units?
Anyway, good to see someone post a fully self contained example demonstrating core concepts. At least one thing done right.
The post doesn't say anything about runtime resource limits, which I agree is a strange omission given the architecture they've chosen. I suppose someone could try building a bot that uses more and more resources, and see when it stops working.
There's a section about making HTTP requests (https://core.telegram.org/bots/serverless#http), which mentions "two constraints: * Response content is textual (binary payloads aren't supported). * The total response is capped at 32 MB. That cap covers the whole response — streaming with res.body lets you process a large body incrementally, but it does not raise the limit." Unclear whether the 32 MB limit is per outgoing request, or shared among all outgoing requests made by a single handler invocation. Also unclear what other limits apply. Non-HTTP protocols presumably are not available.
Clever idea! Although after reading it briefly I see a need for secrets storage.
I've made one Telegram bot hosted on VPS with Docker and cloud LLM. It also interacts with a few other outside services and all credentials are injected via env vars now.
Should I push them as `.env` file for Telegram serverless?
Pretty sure you can't do this, you'd need to instead move them into a lib/secrets.js file (which you'd then add to .gitignore).
It does seem kind of odd that they have so little support for developer amenities like secrets management, dependency management, cron tasks, TypeScript, etc, and didn't shape their API in a way that suggests that stuff's coming later. I don't think it'd be that hard to clone the parts of the Cloudflare Workers API that offer that stuff (workerd is even open source, and offers out of the box the V8-based tenant isolation that they need). Perhaps they don't want to support npm packages because this'd make people more likely to run into undocumented code-size limits?
It looks like they are making their own cloud, with such a little team?
Also we should be using Matrix but it doesn't have half of the features (no channels, no mini apps etc).
Also I wonder whether compiling JS to native code is worth the hassle or not. In browser, it would slow down page load, but here you need to compile only on deploy.
I thought this was about P2P messaging (without servers, hence server "less"), but no, obviously "serverless" on HN has to mean "run code on someone else's servers"..
I always wondered how telegram could afford being free. A chat is expensive to run, a chat with gigantic media quotas even more, and they don't have ads.
There is no way their premium plan cover their cost, espacially with their extensive bot API that multiplies their traffic tenfold.
38 comments
[ 3.5 ms ] story [ 61.0 ms ] threadSetup was quick enough but it needs a real phone number once during setup which is kind of a hassle. still better than using telegram which has no encryption for the bot backend so the devs can read everything you write
I run my agent over Signal with this, the only difference with Telegram is you need to host this. Other than that, it's great.
Source: https://t.me/devs/199669
before it was a better WhatsApp alternative. now either WhatsApp or Signal.
> Each invocation runs in a lightweight V8 isolate, close to Telegram's own systems, so calls to the Bot API and your database are quick and reliable.
Telegram’s servers are distributed worldwide. I understand that the calls to the Bot API may be quick because the serverless code would be propagated to the edge, but how does it handle an SQLite DB? Is that also replicated to guarantee quick access from anywhere?
And why is it one huge single page of word salad instead of self-contained units?
Anyway, good to see someone post a fully self contained example demonstrating core concepts. At least one thing done right.
1) storage limits? 2) can access the internet? If so: bandwidth limits?
Thanks!
There's a section about making HTTP requests (https://core.telegram.org/bots/serverless#http), which mentions "two constraints: * Response content is textual (binary payloads aren't supported). * The total response is capped at 32 MB. That cap covers the whole response — streaming with res.body lets you process a large body incrementally, but it does not raise the limit." Unclear whether the 32 MB limit is per outgoing request, or shared among all outgoing requests made by a single handler invocation. Also unclear what other limits apply. Non-HTTP protocols presumably are not available.
I've made one Telegram bot hosted on VPS with Docker and cloud LLM. It also interacts with a few other outside services and all credentials are injected via env vars now.
Should I push them as `.env` file for Telegram serverless?
It does seem kind of odd that they have so little support for developer amenities like secrets management, dependency management, cron tasks, TypeScript, etc, and didn't shape their API in a way that suggests that stuff's coming later. I don't think it'd be that hard to clone the parts of the Cloudflare Workers API that offer that stuff (workerd is even open source, and offers out of the box the V8-based tenant isolation that they need). Perhaps they don't want to support npm packages because this'd make people more likely to run into undocumented code-size limits?
Also we should be using Matrix but it doesn't have half of the features (no channels, no mini apps etc).
Also I wonder whether compiling JS to native code is worth the hassle or not. In browser, it would slow down page load, but here you need to compile only on deploy.
Which was one of the most non-sensical word to say "You don't maintain the server".
"In @BotFather, open your bot → Serverless and turn it on" .... nop... that setting isn't even there.
There is no way their premium plan cover their cost, espacially with their extensive bot API that multiplies their traffic tenfold.
And now they add free hosting of bots on top?
How the hell are they doing that?
Pretty neat!
(Meanwhile Whatsapp's API-based bot is typically only free at very small volume or during specific free windows how are they so far behind?)