Telegram sin servidor

Documentación percibida como generada por IA

• Muchos comentaristas están convencidos de que la documentación de Telegram Serverless está escrita por un LLM, citando:
  • Patrones repetidos como “no X, no Y, no Z”.
  • Uso excesivo de adverbios concretos (p. ej., “silently”, “quietly”) y texto en negrita.
  • Ciertos tics sintácticos, estructuras cargadas de negaciones y un estilo “contundente”.
• Algunos sostienen que estas señales solo son obvias para usuarios muy online / técnicos; otros señalan que los hablantes no nativos o lectores menos expuestos a la IA quizá no las noten.
• Se comparte un enlace a documentación sobre “Signs of AI writing” en otro sitio.
• Unos pocos ven el uso no revelado de IA como “barato” o una pérdida de tiempo; otros dicen que encaja bien con documentación larga y tediosa que cada vez más leerán otros LLMs de todos modos.

Arquitectura y capacidades

• Los bots serverless se ejecutan en aislados V8 ligeros, cerca de los sistemas de Telegram.
• Una base de datos SQLite integrada por bot se considera una gran ventaja de conveniencia; los límites de tamaño no están documentados.
• Los bots pueden hacer solicitudes HTTP con:
  • Respuestas solo de texto.
  • Un límite de respuesta de 32 MB (no está claro si por solicitud o por invocación).
  • Sin acceso directo a sockets que no sean HTTP, por lo que el tráfico es visible para Telegram a nivel de URL.

Centros de datos y replicación de SQLite

• La infraestructura de Telegram se describe como un pequeño número de centros de datos lógicos (DCs); cada usuario y bot está vinculado a un “home DC”.
• Las escrituras ocurren solo en el home DC; los bots generalmente también se ejecutan allí.
• Esto sugiere que SQLite probablemente no está replicado globalmente; la mayoría de las interacciones se quedan dentro de un solo DC, simplificando la consistencia.
• Los rankings globales y funciones similares podrían ser complicados; sigue sin estar claro cómo se maneja exactamente SQLite.

Límites, madurez y ergonomía para desarrolladores

• Todavía no hay información clara sobre:
  • Tiempo de ejecución, CPU, memoria o cuotas de ancho de banda.
  • Límites de almacenamiento para la base de datos SQLite.
• La gestión de secretos parece mínima:
  • No hay store de variables de entorno / secretos de primera clase; se sugiere incluir un archivo “secrets.js” fuera del control de versiones.
• Carece de comodidades como dependencias npm, soporte para TypeScript, cron jobs y APIs de runtime más ricas; algunos creen que copiar el modelo de Cloudflare Workers ayudaría.
• Solo se admite JavaScript; algunos lamentan el dominio continuo de JS.

Precio, modelo de negocio y beta cerrada

• No se ha publicado información sobre precios; varias personas se sienten incómodas construyendo sobre ello sin un modelo claro.
• Unos pocos deducen que por ahora es gratis porque está en beta cerrada; se cita como confirmación un enlace a un chat de Telegram para desarrolladores.
• Algunos sostienen que el coste incremental de ejecutar funciones JS es pequeño en comparación con los costes totales de almacenamiento y ancho de banda de Telegram.
• Debate más amplio sobre la sostenibilidad de Telegram:
  • Un bando cree que chat + multimedia + bots a gran escala es muy caro y poco probable que se cubra solo con planes premium.
  • Otros dicen que el chat en sí es relativamente barato; los principales costes son el almacenamiento de grandes archivos multimedia.
  • Se mencionan anuncios y cuentas premium como fuentes de ingresos; la implicación en cripto y un comportamiento “sospechoso” en el pasado generan dudas en algunos.
• Los escépticos temen el lock-in futuro y cambios en los precios una vez que los desarrolladores inviertan.

Comparación con otras plataformas de mensajería

• Varios usuarios elogian la API de bots de Telegram por ser mucho más madura y accesible que la de WhatsApp:
  • La API empresarial de WhatsApp se percibe como pesada en trámites, dependiente de partners y monetizada hacia empresas.
• Signal:
  • Algunos ven la ausencia de una API de bots como una feature para privacidad y simplicidad.
  • Otros dicen que es un bloqueo para la migración porque dependen de ~10+ bots personales de automatización en Telegram.
  • Soluciones de terceros como signald ofrecen a Signal una API tipo bot, pero requieren autoalojamiento.
  • Se menciona que usar bots de Telegram expone el contenido a Telegram (no hay E2EE en el backend del bot), mientras que los bots basados en Signal pueden preservar más privacidad; se mencionan detalles sobre los requisitos del número de teléfono de Signal, pero no quedan del todo resueltos.

Spam, bots y experiencia de usuario

• Algunos describen la parte pública de Telegram como “llena de bots y spam”:
  • Otros responden que los bots son la principal fortaleza de Telegram y extremadamente útiles para automatización e integraciones.
  • Muchos dicen que el spam se relaciona sobre todo con unirse a canales/grupos públicos de baja calidad; los grupos privados con gente conocida ven poco spam.
• Algunos proponen pequeñas tarifas para usuarios para disuadir a bots de spam; otros enfatizan que los bots oficiales no pueden escribir primero a los usuarios y están claramente marcados.

Casos de uso y alternativas

• La gente comenta usar bots serverless como:
  • UI para scripts personales, notificaciones, precios de energía, alertas de caída de servidores.
  • Frontends para LLMs (vía OpenRouter o similar), dando reglas personalizadas, almacenamiento y memoria.
• Unos pocos sugieren simplemente usar plataformas ya establecidas como Cloudflare Workers para alojar los backends de bots en su lugar, citando madurez y precios sólidos.
• Aparece cierta confusión sobre activar el toggle de “serverless” en BotFather; otros aclaran que actualmente es solo beta cerrada.
• Nota terminológica: algunos no ven con buenos ojos que “serverless” signifique “corre en los servidores de otro”, pero reconocen que el término es estándar en la industria.