• O dia em que a LLM derrubou o isaCloud

    Reading Time: 2 minutes

    Era uma vez… não, foi hoje mesmo.

    No final de semana passado comecei a implementação do gerenciador de failover do isaCloud – o isaCloud HA Manager. Foi uma codificação intensa e consegui liberar no mesmo final de semana a versão de testes da aplicação.

    Ela é um daemon feito em Go onde criei algumas rotinas para assegurar a role de cada servidor do cluster, revisando o estado de serviços, replicação e endereçamento do serviço.

    Eu costumo codificar com um auxílio básico de LLM para codificação. Utilizo o Windsurf (antigo Codeium) que oferece um serviço razoável para me economizar digitação de algumas linhas de códigos e lógicas repetidas ao longo do projeto.

    Mas eu fui pega pela comodidade e aceitei uma sugestão do assistente para fazer a transposição de um objeto io.ReadCloser (o body da resposta de uma API) para uma estrutura personalizada IPInfoT usando json.NewDecoder().

    client := &http.Client{}
    resp, err := client.Do(&req)
    if err != nil {
      log.Error.Println("error getting public IP:", err)
      return err
    }
    defer resp.Body.Close()
    var ipInfo IPInfoT
    err = json.NewDecoder(resp.Body).Decode(&ipInfo)
    if err != nil {
      log.Error.Println("error decoding ipinfo.io response:", err)
      return err
    }

    Porém eu sempre realizei essas operações usando json.Unmarshal().

    client := &http.Client{}
    resp, err := client.Do(&req)
    if err != nil {
      log.Error.Println("error getting public IP:", err)
      return err
    }
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
      log.Error.Println("error getting public IP - body reading:", err)
      return err
    }
    var ipInfo IPInfoT
    err = json.Unmarshal(body, &ipInfo)
    if err != nil {
      log.Error.Println("error decoding ipinfo.io response:", err)
      return err
    }

    Ao aceitar a sugestão da LLM usando a função destacada no primeiro código, quando a aplicação recebeu uma resposta do serviço ipinfo.io que não batia com o contrato da estrutura IPInfoT, a função não disparou um erro, fazendo com que o tratamento na linha subsequente, que verifica se err != nil não fosse validado e a rotina seguiu adiante, com uma informação inválida na variável ipInfo que ao ser comparada com o ip atual do serviço (que responde no hostname im.isacloud.cc), identificou que o servidor estaria no modo standby, porém ele é primário.

    Ao identificá-lo (incorretamente) como standby, a aplicação estava mandando o container que roda o serviço do isaCloud parar – e por isso toda vez que eu iniciava o container, segundos depois ele era derrubado “gracefully” e não reiniciava sozinho.

    A moral da história é…. releia o código e identifique se algum padrão teu foi modificado por sugestão de LLM… e revise! No meu caso, nem o teste para o tratamento de erro pegou esse caso excepcional.

    E foi assim que a LLM derrubou o serviço isaCloud.

    Com ranço (pela LLM) e carinho por vocês,

    Isadora

  • Interrupção no serviço isaCloud 2026-02-06 🐞

    Reading Time: 2 minutes

    Na madrugada de hoje, 06/02/2026, o serviço do isaCloud ficou indisponível às 01:45:

    Nesse momento, recebemos o alerta, porém devido a um impeditivo (muito sono), não foi iniciada nenhuma investigação.

    Às 6:40 iniciamos o troubleshooting e percebemos que o container que roda o serviço do isaCloud no servidor primário estava parado, com código de saída 137. O mesmo não reiniciava sozinho porque ele é configurado para política restart: unless-stopped. E isso já era um indicativo 🕵️‍♀️.

    Percebemos que ao iniciar o container novamente, o mesmo sempre parava após alguns segundos – impreterivelmente.

    Eventualmente isso ocorre com containers em caso de shared memory sendo excedida – e daí o container para. Fizemos o ajuste no docker-compose.yaml para setar um shm_size maior que o padrão do Docker que é muito pequeno. E então…. nada.

    Imaginamos que poderia estar ocorrendo algum bug inesperado na versão do Docker. Foi feito update dos pacotes e….RÁ! Nada…

    Foi então que começamos a desligar outros mecanismos que funcionam em conjunto com o serviço do isaCloud. Paramos o lsyncd e o novíssimo isaCloud HA Manager. E então…. FUNCIONOU, o container não caiu mais.

    Pois bem, eram 7:20 e era hora de tomar banho e sair pro escritório.

    Chegando no escritório fomos investigar os logs do lsyncd e do isaCloud HA Manager.

    O log do lsyncd aparecia um shutdown limpo, com SIGTERM, padrão. Próximo log a ser investigado era do isaCloud HA Manager (que está em validação ainda).

    Ao olhar o log do isaCloud HA Manager, no horário das 01:45 da manhã…

    A verificação de DNS externa do IP para onde o isaCloud está apontando começou a falhar. O serviço ipinfo.io parou de responder as requisições, gerando um valor inconsistente para a variável que contém o IP atual (nil) e por um bug, ao invés do isaCloud HA Manager abortar a rotina que assegura a role do servidor (primário ou standby), ele seguiu adiante entendendo que o servidor era standby e, com isso, parava o container do serviço.

    Pois é… se a Cloudflare e a AWS estão sujeitas a bugs que geram impacto em seus serviços, o isaCloud também 😇.

    O código do isaCloud HA Manager que estava em testes vai ser corrigido, criando condições melhores para tratamento de erros bobos como esse, especialmente quando é alguma rotina que depende de um serviço externo.

    Aprendizados

    Dos aprendizados desse incidente, temos:

    • Ser mais inteligente na hora de programar 🫏
    • Continuar firme sem vibe coding
    • Jamais parar de evoluir o serviço para que ele continue sendo confiável

    Com carinho,

    Isadora,
    The XMPP Lady (fail edition)

  • O isaCloud HA Manager está no forno

    Reading Time: 2 minutes

    No último ano que passou o isaCloud precisou fazer três vezes o acionamento da sua contingência devido a incidentes registrados em duas regiões do datacenter em que opera aqui no Brasil – além dos 3 datacenters na Europa.

    A estrutura no Brasil é a principal, pois atende integralmente o isaCloud Messenger – ou só isaCloud, para os íntimos.

    Em cada uma das situações em que nossa contingência foi colocada à prova, realizamos com sucesso as inversões de papéis dos servidores primário e secundário, porém alguns processos nitidamente podiam ser mais eficientes e mais automatizados.

    Cada incidente gera um post-mortem que, por sua vez, registra os aprendizados absorvidos na recuperação do serviço. Nesse sentido, aprimoramos um pouquinho mais nosso mecanismo de ativação de contingência em cada uma das situações enfrentadas.

    Mas agora em 2026 tem algo a mais sendo programado – literalmente, codificado: o isaCloud High Availability Manager é um serviço que está sendo desenvolvido “em casa” para controlar a disponibilidade das infraestruturas primária e secundária e executar todos os “blambers” (tecniquêses) necessários para que a ativação da contingência seja totalmente automática no momento em que a operadora do sistema “apertar um grande botão vermelho” em sua mesa.

    Sim, sim, existem diversas ferramentas para gerenciamento de failover (corosync, keepalived, etc), mas tem uma razão forte para criarmos a nossa própria: a gente queria isso 🙂

    Hoje o isaCloud HA Manager está em modo “dry run”, ou seja, ainda sem executar nenhuma mudança automática, mas nos próximos dias ele entrará em produção e com certeza faremos as devidas celebrações para dividir essa conquista.

    E por quê investir tempo e esforço em escrever um mecanismo próprio? Porque dedicação e carinho não são economizados para que cada usuário do isaCloud tenha uma experiência confiável.

    E nessa meta do uptime infinito, seguimos firmes!

    Com carinho,

    Isadora.

  • Vou sempre lutar pelo xmpp

    Reading Time: 2 minutes

    Em 2025 os assuntos soberania nacional e liberdade ganharam muita força no âmbito digital. Do jeito que os maiores figurões do mercado de tecnologia iniciaram o ano de 2025 com seus apoios quase irrestritos às políticas do presidente americano eleito, emergiu um despertar de milhares de pessoas sobre como isso era um sinal de alerta e o que fazer a respeito.

    Eu fui uma das pessoas cutucadas por esse sinal de alerta. Eu saí do meu estado de inércia e conformação para retomar minha luta pela liberdade de escolha, pela privacidade e pelo respeito às pessoas. Em todos os contextos em que eu vi que poderia batalhar, o fiz. Não pensei duas vezes.

    O isaCloud foi uma resposta imediata em Janeiro de 2025: eu não aceitaria passivamente ser um produto da “Beta” e comprometer a minha privacidade e das pessoas com quem me relaciono, simplesmente aceitando a forma como os produtos dessa empresa eram nocivos.

    Nesse sentido, em 2025 eu não parei de lutar 1 dia sequer, seja fomentando o isaCloud para novos usuários, seja apoiando projetos que utilizassem XMPP, seja educando pessoas e coletivos sobre a importância de se adotar um protocolo realmente livre e federado de comunicação.

    Em 2026 não será diferente: se você me falar que tem uma ideia de projeto que envolva soberania e liberdade, eu vou te convencer a incluir XMPP na sua iniciativa.

    Eu preciso aproveitar e ressaltar algumas questões sobre esse tema:

    • Provisionar um serviço XMPP é barato
    • Operar um serviço XMPP chega a ser chato, de tão pouca mão na massa que dá
    • Manter um serviço XMPP baseado em convites praticamente zera a possibilidade de spam
    • O protocolo é seguro e confiável – são 27 anos de trabalho

    E você? Não entende muito do assunto mas quer lutar junto?

    Então basta falar a respeito, indicar este blog ou me mencionar no fediverso (@isadora@transverso.org).

    Portanto, se prepara porque a “XMPP Lady” vai “incomodar” bastante para te trazer pro lado certo da força.

    Com carinho,
    Isadora, a XMPP Lady

  • Interrupções no serviço isaCloud 2026-01-13

    Reading Time: 2 minutes

    Na terça-feira, dia 13/01/2026, por volta de 06:40 AM foi percebida uma instabilidade na conexão com o servidor primário que atende o isaCloud Messenger na região nordeste-1 do datacenter Magalu Cloud.

    Nesse momento, tentamos acessar a console de gerenciamento dos serviços no Magalu Cloud, porém a própria console estava indisponível – já era um sinal de que algo mais generalizado estava ocorrendo.

    Conseguimos abrir chamado com o time do Magalu Cloud, informamos qual a instância e região que estavam indisponíveis e recebemos a informação de que o time de engenharia já estava atuando.

    Ficamos acompanhando na página de status de serviços deles e de fato o incidente foi registrado. Apesar de não especificar o problema, indicava que o serviço de Virtual Machines da região NE-1 estavam sendo impactados.

    A linha do tempo do incidente deles está neste link:

    https://status.magalu.cloud/incident/AthcGya5reLhDSid0WReNRcYrBAn5biUjH5iIhWyX-tLvo5gFdkQqRbyMIq-CwDIrV18uBzuQSGji6lCJtDNng==

    Do lado do isaCloud, ativamos nossa contingência na região BR-SE-1 (São Paulo) por volta de 8:40 AM. Usuários levaram no máximo 1h para conseguirem reconectar após a ativação da contingência devido à propagação de DNS na desec.io.

    Algumas medidas foram tomadas após o incidente para reduzir ainda mais o tempo de ativação da contingência:

    • Entradas no desec.io foram configuradas como CNAME para entradas que estão na Cloudflare pois esta oferece um TTL bem mais baixo (300s contra 3600s da desec.io).
    • O mecanismo de detecção dos papéis primário / standby do nosso cluster irá executar algumas ações automaticamente tão logo identificar uma mudança nesses papéis.

    Por fim, gostaria pessoalmente de agradecer a todos os usuários pela compreensão de sempre e garantir que os 2 incidentes ocorridos em 1 ano de operação do isaCloud resultaram num amadurecimento dos nossos processos de backup e contingência.

    Saibam que o isaCloud é provido com muito carinho e comprometimento com cada um de vocês 💜

    Com carinho,
    Isadora

  • Serviços federados são mais seguros

    Reading Time: 2 minutes

    Saiu na mídia que pesquisadores divulgaram uma brecha de segurança no WhatsApp que expõe os dados de praticamente todos os 3,5 bilhões de usuários do serviço.

    O que esse tipo de fato nos faz refletir é o risco que um serviço privado com tantos usuários traz consigo. Lembra quando sua avó dizia “não coloque todos os ovos num único cesto”? É sobre isso.

    O WhatsApp se tornou infraestrutural, isto é, não paramos mais pra pensar no custo que sua utilização tem para nós, usuários.

    O fato desse aplicativo reunir tantos usuários e tantas informações sobre cada um de nós coloca um alvo enorme na sua infraestrutura e na sua segurança.

    Nesse sentido, os serviços que funcionam em modo de federação, isto é, um ecossistema onde usuários se dividem em milhares ou milhões de diferentes instâncias, oferecem alguns benefícios reais em termos de segurança.

    O fato de instâncias não reunirem um número tão expressivo de usuários naturalmente reduzem tanto o interesse por uma exploração por vulnerabilidades quanto o impacto gerado por esse tipo de ataque.

    Além disso, serviços federados e voltados a comunidades não utilizam dados de seus usuários para fins comerciais, logo, não há enriquecimento “ilícito” de informações sobre cada conta.

    Se o conceito de federação está abstrato, observe a imagem abaixo…

    Cada micro pontinho azul é uma instância (servidor) XMPP ao redor do mundo. Cada aglomeração visível mostra as interconexões entre dezenas, centenas e até milhares de servidores XMPP uns com os outros, formando grandes “galáxias”.

    Dando um zoom, dá para visualizar um pouco mais essas interconexões:

    Você percebe que cada instância que aparece nesse recorte – xmpp.eco.br e jabber.no – fazem parte de uma grande malha de servidores e interconexões, todos falando o mesmo protocolo e permitindo que seus usuários conversem livremente com pessoas de outras instâncias.

    A federação utilizada pelo isaCloud e todos demais serviços baseados em XMPP é natural e orgânica como nosso próprio Universo e representa a forma mais saudável, mais balanceada de se desfrutar de uma vida digital livre de grandes muros que acabam sendo impostos pelas bigtechs.

    E lembre-se: traga as conversas que mais importam para sua vida pro isaCloud. 🙂

    Com carinho,

    Isadora


    Nota: para explorar os mapas exibidos neste post, acesse https://xmppnetwork.goodbytes.im – mas cuidado que é bem “pesado” 🙂

  • Interrupções no serviço isaCloud em 25 e 27/10/2025

    Reading Time: < 1 minute

    Nos últimos dias o serviço isaCloud passou por dois momentos de interrupção de serviço causados por uma falha técnica no ambiente de nuvem no datacenter primário utilizado pelo mensageiro.

    O isaCloud utiliza uma estrutura que conta com 4 datacenters, sendo dois no Brasil (Magalu Cloud) – um na região sudeste e outro na região nordesta – e dois na Europa (Contabo, Scaleway) – em dois diferentes provedores na Alemanha. Essa estrutura mantém uma replicação de 3 datacenters em tempo real e o 4º datacenter como base de monitoramento.

    Estamos ainda buscando com o Magalu Cloud mais detalhes técnicos sobre a interrupção de serviços que afetou nossa estrutura primária na região sudeste, mas no dia 25/10/2025 houve pelo menos um incidente em escala que foi reportado na status page deles:

    https://status.magalu.cloud/incident/AthcGya5reLhDSid0WReNRcYrBAn5biUjH5iIhWyX-vFGxu2AVIl1XMKcVUe4263npb7HAJWa_x3E6xjZMqFow==

    Sobre o incidente do dia 27/10/2025, ainda estamos buscando mais detalhes.

    A indisponibilidade total das duas interrupções somadas foi de mais de 20h, sendo que, no dia 27/10/2025, quando estava completando 3h de interrupção, executamos o plano de contingência e ativamos o datacenter secundário em outra região no Brasil.

    Conforme novas informações chegarem, atualizaremos esta publicação.

    Com carinho,
    Isadora

    Atualização – 28/10/2025 15:50

    Conforme o RCA enviado pelo time Magalu Cloud, o que afetou a instância primária do isaCloud tanto no dia 25 quanto no dia 27 foi uma falha no tenant físico onde estavam diversas instâncias. Foi confirmado pelo time deles que as instâncias foram migradas para um outro tenant do cluster.

    Por hora o isaCloud utilizará outra região como site primário e manterá o mecanismo de replicação para as demais regiões do Magalu, bem como para os 2 datacenters alocados na Europa.

    Com carinho,
    Isadora

  • O caminho parece estar certo, mas será desafiador

    Reading Time: 3 minutes

    Saiu uma reportagem da BBC News Brasil sobre o aplicativo indiano que quer desafiar a supremacia do WhatsApp e eu comecei a ler – incrédula, admito – porque normalmente essas matérias tem um título atraente e um conteúdo muito raso.

    Ao seguir passando meus olhos pelo texto, comecei a ficar cada vez mais atenta, porque o que está sendo reportado de fato é interessante.

    Contexto

    Tem uma empresa indiana que eu acompanho e uso serviços há muitos anos chamada Zoho. Eles possuem diversas soluções tanto para pessoas físicas quanto para empresas e até profissionais da área de operações de tecnologia como eu. Eles são os donos do Site 24×7, da suíte Zoho que compete com Google Workspace e alguns outros produtos.

    O fato é que a Zoho vem trabalhando num aplicativo de mensagens instantâneas chamado Arattai, que possui basicamente as mesmas funcionalidades básicas dos demais comunicadores, como mensagens um a um, grupos, chamadas de áudio e chamadas de vídeo.

    O fato surpreendente é que o Primeiro Ministro da Índia começou a falar publicamente em sua conta no Twitter (me nego a chamar de X) para que os indianos usassem o Arattai, que valorizassem a independência e soberania indiana. O contexto dessa fala não deixa de ter relação com as recentes mudanças nas relações comerciais entre o ocidente (US) e a Índia e o fato da Índia ser o maior mercado do WhatsApp com mais de 500 milhões de usuários num único país.

    Não quero aqui reproduzir a matéria da BBC, linkada ao final deste texto, mas especialistas sabem que vai ser difícil o Arattai romper a extensa base de usuários do WhatsApp, mas isso não significa que o Arattai não tenha uma jornada de sucesso pela frente.

    Tá, mas o que isaCloud tem a ver com isso?

    Vamos ver como isaCloud se compara ao Arattai.

    FuncionalidadeArattaiisaCloud
    Mensagens 1:1
    Grupos privados
    Canais públicos
    Chamadas de voz
    Chamadas de vídeo
    Transferência de arquivos
    Stories
    Login em múltiplos dispositivos
    Critpografia ponta a ponta nas chamadas de voz e vídeo
    Criptografia ponta a ponta nas mensagens 1:1 e grupos

    A tal privacidade

    Segundo o CEO da Zoho, eles pretendiam lançar o Arattai somente depois de implementar a criptografia ponta a ponta, porém acabaram antecipando por uma questão de pressão mercadológica (ou seria governamental?).

    Eu, como CEO do isaCloud, não faria isso, mas é fato que os usuários comuns não estão sequer cientes do que isso significa. Mas, pela proteção deles, eu não faria assim mesmo.

    Fora isso, tem uma questão fundamental no Arattai que é a pressão do governo para que o Arattai compartilhe dados com o poder público em situações “específicas”. Sabemos que todos os governos tem essa questão e que empresas que possuem uma envergadura jurídica e mercadológica usam todos os recursos necessários para “proteger” a privacidade dos seus usuários.

    Nesse ponto eu sou MUITO clara: o isaCloud tem a tranquilidade de armazenar um mínimo de metadados (descritos em nossa política de privacidade) para o funcionamento do serviço. Se formos acionados judicialmente para compartilhar informações acerca de algum processo ou investigação policial oficial, é claro que iremos compartilhar os poucos metadados disponíveis; porém, o teor / conteúdo do que nossos usuários trafegam é teoricamente inquebrável* pois as chaves criptográficas residem exclusivamente nos dispositivos de cada usuário.

    Conclusão

    Sei que o isaCloud e nenhum outro mensageiro livre, que respeita a privacidade dos usuários e que não usa dados dos usuários como moeda vai atingir uma popularidade tão grande, mas acredito piamente que vamos conseguir conquistar cada vez mais adeptos dentre os que escolheram a pílula vermelha de Matrix.

    Sobre o Arattai, desejo sucesso, de verdade. Seria muito bom ver uma iniciativa capaz de fazer um mínimo de barulho no universo dos mensageiros.

    Com carinho,
    Isadora.

    – – – –

    Link para matéria da BBC:
    https://www.bbc.com/portuguese/articles/ced5qy7ggzgo

    * Criptografias modernas podem ser teoricamente quebradas apenas com tecnologia quântica ou com poder computacional que talvez só a tal NSA tenha.

  • Impactos do ECA Digital

    Reading Time: 2 minutes

    A aprovação e sanção presidencial da Lei Felca – também conhecida por ECA Digital – vem para colocar uma série de obrigações para qualquer site ou serviço voltado para menores de 18 anos ou que estes possam ter acesso.

    Venho acompanhando pela mídia e pelo próprio documento da lei o que ela determina no sentido tanto da proteção dos menores quanto na limitação do acesso a serviços projetados para maiores de 18 anos.

    Desde o início tenho ficado em dúvida quanto a aplicabilidade dos processos de validação de identidade e idade.

    Sendo assim, pesquisei a respeito desse tema e existe uma série de soluções – nacionais, inclusive – que oferecem diferentes formas para identificar e validar uma pessoa que está acessando um serviço digital. Okay, talvez eu tenha entendido que sim, é tecnicamente viável validar identidades – inclusive usando o conceito de ZKP (Zero Knowledge Proof), onde uma identidade é validada, é gerado um token para a aplicação mas a aplicação não sabe os dados da pessoa que passou pela autenticação – mas para esse caso eu não encontrei ainda um fornecedor nacional.

    Conversando com um colega ele deu algumas sugestões que são bem factíveis também, como, por exemplo, fazer uma autenticação integrada com o Google, usando fluxo oAuth2, pois o Google é um serviço que requer que a pessoa seja maior de idade – nesse caso, a gente acaba terceirzando a responsabilidade e contando com a possibilidade do Google vir a implementar um mecanismo de validação de identidade para suas contas.

    Outra opção tecnicamente viável seria fazer uma transação num cartão de crédito, num valor simbólico de R$ 0,01 e que se fizesse o estorno imediato: nesse caso contamos com a credibilidade da operadora de cartão que não pode emitir cartão para menor – pelo menos não sem estar vinculado a um cartão de responsável.

    Mas o ponto é: eu não gostaria de dificultar a entrada de pessoas no isaCloud. Ele é para ser simples, familiar, para uma comunidade pequena. Além disso, é um serviço com financiamento próprio, sem nenhum recurso financeiro para ir atrás de soluções de validação de identidade e, principalmente, o isaCloud não tem registro aberto ao público, somente mediante convite.

    Eu realmente espero que a Lei Felca passe por revisões e que alguns requisitos sejam revisitados, seja no porte de quem provê o serviço, seja no volume de usuários.

    Esperar que o isaCloud tenha de cumprir as mesmas exigências que o WhatsApp da bilionária Meta é um tanto irreal.

    Não sei para onde isso tudo vai caminhar, mas eu vou fazer TUDO que estiver ao meu alcance para que o isaCloud esteja sempre disponível para você continuar mantendo as conversas e pessoas que mais importam pra você, por perto.

  • Diga seu nome, demônio!

    Reading Time: < 1 minute

    Hoje foi um dia interessante porque um amigo querido, sysadmin como eu, estava enfrentando uma questão de leak de memória no serviço de XMPP do ecossistema que ele administra.

    Ficamos num “ping pong” de idéias sobre o que poderia estar gerando aquele comportamento. A princípio o Prosody não demanda muitos recursos mas, no caso dele, o serviço estava “leakando” de tal forma que comprometia o ambiente como um todo onde o serviço está alocado.

    Analisa gráfico daqui, analisa gráfico dali, avalia o que houve de mudança recente no ambiente – nenhuma identificada -, avalia se o volume de sessões server to server e client to server estavam estourando e tal… nada. Nadinha. Nadica.

    Lembro de um pequeno diálogo em que o Blake (personagem do filme Batman – O Cavaleiro das Trevas Ressurge) conversa com o Comissário Gordon. Blake diz: “mas senhor, eu não entendo nada de construções”… e o Comissário responde: “mas você pode entender de padrões! Agora você é meu detetive e não mais oficial de patrulha”.

    Isso é bem real…. quando a gente vai acumulando horas de vôo na nossa profissão ou num hobby a gente vai aprendendo a juntar conexões, padrões e saber alguns caminhos que invariavelmente ajudam a diagnosticar os problemas mais cabeludos e misteriosos.

    Depois de alguns papos no canal XMPP a respeito do misterioso leak, o amigo foi pela abordagem de começar a descarregar os módulos extras do Prosody que foram adicionados mais recentemente… e PÁ! Parece que uma luz apareceu e o “demônio deu sinais de qual era seu nome”!

    Nem foi preciso chamar o Exorcista do Papa, Signore Gabriele Amorth (interpretado por Russel Crowe)… o amigo foi o próprio Leak Exorcist da vez 🙂

    E o nome do demônio? Parece que era mod_cloud_notify_extensions 😈