Telegram Serverless

Perceived AI-Generated Documentation

• Many commenters are convinced the Telegram Serverless docs are LLM‑written, citing:
  • Repeated patterns like “no X, no Y, no Z”.
  • Overuse of specific adverbs (e.g., “silently”, “quietly”) and bold text.
  • Certain syntactic tics, negation-heavy structures, and “punchy” style.
• Some argue these signals are obvious only to highly online / technical users; others note non‑native speakers or less AI‑exposed readers may not notice.
• One link is shared to “Signs of AI writing” documentation elsewhere.
• A few see undisclosed AI usage as “cheap” or a waste of their time; others say it’s a good fit for long, tedious documentation that will increasingly be read by other LLMs anyway.

Architecture and Capabilities

• Serverless bots run in lightweight V8 isolates close to Telegram systems.
• A bundled SQLite database per bot is viewed as a strong convenience feature; size limits are not documented.
• Bots can make HTTP requests with:
  • Text-only responses.
  • A 32 MB response cap (unclear if per request or per invocation).
  • No direct non-HTTP socket access, so traffic is visible to Telegram at the URL level.

Data Centers and SQLite Replication

• Telegram’s infrastructure is described as a small number of logical data centers (DCs); each user and bot is tied to a “home DC.”
• Writes occur only on the home DC; bots generally run there too.
• This suggests SQLite likely isn’t globally replicated; most interactions stay within one DC, simplifying consistency.
• Global leaderboards and similar features could be tricky; how exactly SQLite is handled remains unclear.

Limits, Maturity, and Developer Ergonomics

• No clear information yet on:
  • Execution time, CPU, memory, or bandwidth quotas.
  • Storage limits for the SQLite DB.
• Secrets management appears minimal:
  • No first-class env var / secrets store; suggestions include checking in a “secrets.js” file kept out of version control.
• Lacks conveniences like npm dependencies, TypeScript support, cron jobs, and richer runtime APIs; some think copying Cloudflare Workers’ model would help.
• Only JavaScript is supported; some lament the ongoing dominance of JS.

Pricing, Business Model, and Closed Beta

• No pricing info is published; multiple people are uneasy about building on it without a clear model.
• A few infer it’s free for now because it’s in closed beta; a Telegram dev chat link is cited as confirmation.
• Some argue the incremental cost of running JS functions is small compared to Telegram’s overall storage and bandwidth costs.
• Broader debate on Telegram’s sustainability:
  • One side believes large-scale chat + media + bots is very expensive and unlikely to be covered by premium tiers alone.
  • Others say chat itself is relatively cheap; main costs are storage of large media.
  • Ads and premium accounts are mentioned as revenue sources; crypto involvement and past “shady” behavior raise doubts for some.
• Skeptics worry about future lock‑in and pricing changes once developers invest.

Comparison with Other Messaging Platforms

• Several users praise Telegram’s bot API as far more mature and accessible than WhatsApp’s:
  • WhatsApp’s business API is seen as paperwork-heavy, partner-driven, and monetized toward businesses.
• Signal:
  • Some see the lack of a bot API as a feature for privacy and simplicity.
  • Others say it’s a blocker to migration because they rely on ~10+ personal automation bots on Telegram.
  • Third-party solutions like signald give Signal a bot-like API but require self‑hosting.
  • It’s mentioned that using Telegram bots exposes content to Telegram (no E2EE on the bot backend), whereas Signal-based bots can preserve more privacy; details around Signal’s phone-number requirements are mentioned but not fully resolved.

Spam, Bots, and User Experience

• Telegram’s public side is described as “full of bots and spam” by some:
  • Others counter that bots are Telegram’s core strength and extremely useful for automation and integrations.
  • Many say spam is mostly tied to joining low‑quality public channels/groups; private groups with known people see little spam.
• Some propose small user fees to deter spam bots; others emphasize that official bots can’t message users first and are clearly marked.

Use Cases and Alternatives

• People discuss using serverless bots as:
  • UI for personal scripts, notifications, energy prices, server downtime alerts.
  • Frontends for LLMs (via OpenRouter or similar), giving custom rules, storage, and memory.
• A few suggest simply using established platforms like Cloudflare Workers for hosting bot backends instead, citing maturity and robust pricing.
• Some confusion appears about enabling the “serverless” toggle in BotFather; others clarify it’s currently closed beta only.
• Terminology note: some dislike “serverless” meaning “runs on someone else’s servers,” but acknowledge the term is industry‑standard.