Telegram Serverless

Documentação percebida como gerada por IA

• Muitos comentaristas estão convencidos de que a documentação do Telegram Serverless foi escrita por LLM, citando:
  • Padrões repetidos como “no X, no Y, no Z”.
  • Uso excessivo de advérbios específicos (por exemplo, “silently”, “quietly”) e de texto em negrito.
  • Certas manias sintáticas, estruturas fortemente negativas e um estilo “direto”/“de impacto”.
• Alguns argumentam que esses sinais são óbvios apenas para usuários muito online / técnicos; outros observam que falantes não nativos ou leitores menos expostos a IA podem não perceber.
• Um link é compartilhado para uma documentação de “Signs of AI writing” em outro lugar.
• Alguns veem o uso não divulgado de IA como “barato” ou uma perda de tempo; outros dizem que é uma boa opção para documentação longa e tediosa que cada vez mais será lida por outros LLMs de qualquer maneira.

Arquitetura e capacidades

• Bots serverless rodam em isolados V8 leves, próximos aos sistemas do Telegram.
• Um banco de dados SQLite empacotado por bot é visto como um recurso de conveniência forte; os limites de tamanho não estão documentados.
• Bots podem fazer requisições HTTP com:
  • Respostas somente em texto.
  • Um limite de resposta de 32 MB (não está claro se por requisição ou por invocação).
  • Sem acesso direto a sockets que não sejam HTTP, então o tráfego fica visível para o Telegram no nível da URL.

Data centers e replicação do SQLite

• A infraestrutura do Telegram é descrita como um pequeno número de data centers lógicos (DCs); cada usuário e bot está ligado a um “home DC”.
• As gravações ocorrem apenas no home DC; bots geralmente também rodam lá.
• Isso sugere que o SQLite provavelmente não é replicado globalmente; a maioria das interações fica dentro de um único DC, simplificando a consistência.
• Rankings globais e recursos semelhantes podem ser complicados; ainda não está claro exatamente como o SQLite é tratado.

Limites, maturidade e ergonomia para desenvolvedores

• Ainda não há ინფორმაცია clara sobre:
  • Tempo de execução, CPU, memória ou cotas de largura de banda.
  • Limites de armazenamento para o banco SQLite.
• O gerenciamento de segredos parece mínimo:
  • Não há variável de ambiente / cofre de segredos de primeira classe; sugestões incluem fazer commit de um arquivo “secrets.js” mantido fora do controle de versão.
• Faltam conveniências como dependências npm, suporte a TypeScript, cron jobs e APIs de runtime mais ricas; alguns acham que copiar o modelo do Cloudflare Workers ajudaria.
• Apenas JavaScript é suportado; alguns lamentam a dominância contínua de JS.

Preço, modelo de negócio e beta fechado

• Nenhuma informação de preço foi publicada; várias pessoas se sentem desconfortáveis em construir em cima disso sem um modelo claro.
• Alguns concluem que, por enquanto, é grátis porque está em beta fechado; um link para um chat de desenvolvedores do Telegram é citado como confirmação.
• Alguns argumentam que o custo incremental de executar funções JS é pequeno em comparação com os custos gerais de armazenamento e largura de banda do Telegram.
• Há um debate mais amplo sobre a sustentabilidade do Telegram:
  • Um lado acredita que chat + mídia + bots em grande escala é muito caro e improvável de ser coberto apenas por planos premium.
  • Outros dizem que o chat em si é relativamente barato; os principais custos são o armazenamento de mídia grande.
  • Anúncios e contas premium são citados como fontes de receita; envolvimento com cripto e comportamento passado “duvidoso” levantam dúvidas para alguns.
• Céticos se preocupam com lock-in futuro e mudanças de preço depois que os desenvolvedores investirem.

Comparação com outras plataformas de mensagens

• Vários usuários elogiam a API de bots do Telegram por ser muito mais madura e acessível do que a do WhatsApp:
  • A API de negócios do WhatsApp é vista como pesada em burocracia, dependente de parceiros e monetizada para empresas.
• Signal:
  • Alguns veem a ausência de uma API de bots como uma feature para privacidade e simplicidade.
  • Outros dizem que isso é um bloqueio para migração porque dependem de ~10+ bots pessoais de automação no Telegram.
  • Soluções de terceiros como signald dão ao Signal uma API semelhante à de bots, mas exigem auto-hospedagem.
  • É mencionado que usar bots do Telegram expõe o conteúdo ao Telegram (sem E2EE no backend do bot), enquanto bots baseados em Signal podem preservar mais privacidade; detalhes sobre os requisitos de número de telefone do Signal são mencionados, mas não ficam totalmente resolvidos.

Spam, bots e experiência do usuário

• A face pública do Telegram é descrita por alguns como “cheia de bots e spam”:
  • Outros rebatem dizendo que bots são a força central do Telegram e extremamente úteis para automação e integrações.
  • Muitos dizem que o spam está בעיקרamente ligado a entrar em canais/grupos públicos de baixa qualidade; grupos privados com pessoas conhecidas veem pouco spam.
• Alguns propõem pequenas taxas de usuário para desencorajar bots de spam; outros enfatizam que bots oficiais não podem mandar mensagem primeiro para os usuários e são claramente identificados.

Casos de uso e alternativas

• As pessoas discutem usar bots serverless como:
  • UI para scripts pessoais, notificações, preços de energia, alertas de indisponibilidade de servidores.
  • Frontends para LLMs (via OpenRouter ou similares), fornecendo regras personalizadas, armazenamento e memória.
• Alguns sugerem simplesmente usar plataformas estabelecidas como o Cloudflare Workers para hospedar backends de bots, citando maturidade e preços robustos.
• Surge alguma confusão sobre ativar o toggle “serverless” no BotFather; outros esclarecem que, atualmente, isso é apenas beta fechado.
• Observação sobre terminologia: alguns não gostam de “serverless” significar “roda nos servidores de outra pessoa”, mas reconhecem que o termo é padrão da indústria.