71–80 of 114 posts
I did not understand this. What does this do exactly?
A few questions and if someone knows please help: 1) storage limits? 2) can access the internet? If so: bandwidth limits? Thanks!
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 payload…
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.
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?
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?
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.…
Earlier quoted context omitted.
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 payload…
This means the code must pass the URL in cleartext so that Telegram can detect those who try to use bots for scraping and proxies.
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.
Could it be because the author is not very confident in their English skills so they asked an LLM to translate text to a proper English?
Then again, like a sibling said, only LLMs will be reading this anyway.
Earlier quoted context omitted.
This means the code must pass the URL in cleartext so that Telegram can detect those who try to use bots for scraping and proxies.
If you're talking about the lack of support for binary responses, I don't think this'd stop people from using Base64 to tunnel arbitrary payloads? Otherwise I'm not sure what the alternative would be to "passing the URL in cleartext" to an HTTP client.
Earlier quoted context omitted.
Could it be because the author is not very confident in their English skills so they asked an LLM to translate text to a proper English?
It could be, it could also be that they wanted to produce it more cheaply, could be a few valid reasons. It just looks cheap to me, and I thought companies would want to show a better face. Then again, like a sibling said, only LLMs will be reading this anyway.