Autor: isadora

  • Serviços federados são mais seguros

    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

    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

    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

    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!

    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 😈

  • Rumo ao uptime infinito

    Brincadeiras à parte, eu sou a “doida do uptime”. Pelo hábito de trabalhar em operação de plataformas que operam 24×7, todo meu direcionamento é para manter sistemas rodando da forma mais contínua possível.

    Claro, há manutenções que demandam um restart de serviço, restart de host, de hipervisor e etc, mas o esforço é constante para que cada usuário de um serviço gerenciado por mim tenha a maior confiabilidade possível no serviço.

    Com o isaCloud não é diferente. São poucos usuários? São – quase 100 atualmente -, mas cada pessoa importa. A confiança que um usuário deposita no isaCloud como seu meio de comunicação torna minha missão de gerenciar esse serviço digna de carinho e dedicação máximos.

    Batemos mais de 71 dias de uptime no isaCloud, mas provavelmente vem uma atualização de Prosody que vai demandar aquele restart maroto… Nesses casos, tomo o cuidado de sempre avisar toda base de usuários e realizar as manobras num horário de menor impacto possível.

    E o que eu ganho com isso? Um coração quentinho por saber que cada login do isaCloud merece o melhor de mim e que essa confiança faça com que os usuários tragam mais pessoas com quem eles gostariam de manter conversas significativas dentro do isaCloud. 😊

  • O protocolo mais perfeito dos imperfeitos

    Um pouco de contexto

    Como uma XMPP Lady que se preze, atuo vigilante e incessantemente no fediverso e canais XMPP lutando para desmistificar diversas questões relacionadas ao ecossistema do XMPP.

    Essas intervenções acontecem em diferentes tópicos relacionados, desde seu funcionamento em termos de protocolo, na parte backend (servidor) e até a operação dos apps que atuam como clientes de mensagens.

    Na parte de clientes é onde surgem as maiores questões. O protocolo tem uma característica de extensibilidade. Os padrões de funcionamento são organizados em XEPs (XMPP Extension Protocol) e a comunidade de desenvolvedores e organizações envolvidas atuam para implementar essas definições.

    Por se tratar de um software livre, o XMPP tem seus padrões definidos por uma entidade – a XSF (XMPP Standards Foundation) – que trabalha as propostas de extensão e as documenta para que sejam adotadas pela comunidade.

    No dia a dia

    Seguido pessoas leigas e técnicas fazem comparações do WhatsApp, Telegram, Signal e etc com o XMPP. São alegações diversas, como:

    • No WhatsApp é mais fácil migrar de aparelho sem perder as mensagens;
    • No WhatsApp não me preocupo com chaves de segurança;
    • Para ter um novo contato no WhatsApp só tenho que pegar o número de telefone do contato ou ler um QR Code;

    E aí entra a XMPP Lady em ação…

    • No WhatsApp é mais fácil migrar de aparelho sem perder as mensagens;
      No XMPP também! No seu iOS ou Android, ao fazer a migração de aparelhos usando o mecanismo do próprio sistema operacional, seus aplicativos e dados (incluindo suas chaves de criptografia) são movidas de um aparelho para outro transparentemente!
    • No WhatsApp não me preocupo com chaves de segurança;
      E por que você se preocupa com elas no XMPP se elas fazem parte do seu backup ou da migração entre aparelhos?
    • Para ter um novo contato no WhatsApp só tenho que pegar o número de telefone do contato ou ler um QR Code;
      E por que você não pede também o QR Code ou link de convite de contato para quem também usa XMPP? Ou porque não pede o ID da pessoa – sendo este ID um mero endereço e-mail?

    Para além de questões básicas como essa – que demonstram uma pura resistência sem nenhum fato, de fato (perdão a redundância), eu exemplifico um outro comparativo em formato de “FAQ”:

    • Se você trocar de celular ou simplesmente redefinir o telefone de fábrica e não tiver backup do WhatsApp, o que acontece com suas mensagens?

      Resposta: você perde suas mensagens históricas e continua conversando dali para frente.

      E no XMPP? Mesma coisa. Você precisa se backup da conta para ter acesso às mensagens históricas.
    • Se o seu telefone estiver na assistência técnica, como você faz para acessar seu WhatsApp?

      Resposta: se tiver um WhatsApp web já registrado, poderá continuar acessando dali. Se não tiver, ou fica sem acesso ao WhatsApp e incomunicável com as pessoas ou coloca seu número em outro chip, ativa num aparelho, loga no WhatsApp no aparelho e perde o acesso que tinha ao WhatsApp no aparelho anterior, causando uma bagunça nos seus históricos.

      E no XMPP? Você pode seguir usando sua conta em outro dispositivo que já tinha ativado e seguir a vida normalmente. Quando o aparelho voltar da assistência, ele vai sincronizar as mensagens não baixadas ainda do servidor (só varia quanto tempo cada servidor armazena offine, geralmente no mínimo 1 semana). Outra opção é acessar sua conta de outro aparelho ou cliente web qualquer e seguir se comunicando com as pessoas – mas só será possível ler as mensagens a partir do momento em que o novo dispositivo ingressou na sua conta.

    O protocolo perfeito

    Fora as comparações corriqueiras com WhatsApp, surgem as questões relacionadas a outros mensageiros descentralizados. Os mais conhecidos são o Matrix e o Delta Chat.

    De uma forma sucinta vou colocar aqui uma listinha de razões pelas quais eu considero o XMPP o protocolo perfeito dentre os imperfeitos – que são todos, sejam livres ou proprietários.

    • Maturidade: o XMPP está conosco há 26 anos, exatamente o tempo que eu, quem vos escreve, tem de mercado de tecnologia. Seu projeto teve início em 1999.
    • Flexibilidade: há quem diga que a extensibilidade do protocolo dificulta as coisas pros usuários… mas o que eu acredito é que é inerente a um protocolo livre não criar definições estanques sobre como cada servidor ou cliente vai funcionar e que funcionalidades vai implementar: isso fica a cargo da comunidade de desenvolvedores e da comunidade de usuários ajudar na definição do caminho.
    • Multicanal: o XMPP permite a comunicação por texto, voz e vídeo, diferente das outras soluções livres que mencionei antes desta lista.
    • Privacidade: se a pessoa está buscando anonimato, não será no XMPP que ela encontrará essa possibilidade. O XMPP é um protocolo que oferece toda privacidade necessária para sua comunicação e, operando em conjunto com OMEMO, garante a também a integridade e a confidencialidade do conteúdo das mensagens que você trafega. Os servidores XMPP atuam como relays, que conectam duas partes: remetente e destinatário; e, nesse sentido, o máximo de informação sua que há num servidor XMPP, por padrão, são metadados como timestamp de conexão, nome de usuário, nome de usuário de quem está na sua lista de contatos XMPP (chamada roster) e, habilitando um debug no servidor, pode-se auditar com que outro usuário você trocou mensagem, mas nunca o conteúdo dessas mensagens. Inclusive, mensagens offline esperando ser entregues para um dispositivo que está desligado ficam também criptografadas pois apenas o destinatário pode decodificá-la.
    • Federação: o fato de você poder criar sua conta no servidor XMPP administrado por uma comunidade ou pessoa que você confia dá um grau extra de conforto na hora de usar o serviço. Então você tem um ecossistema de milhares de servidores XMPP para escolher onde ter sua conta e diminui drasticamente a possibilidade de ser um alvo potencial de um roubo de dados visto que essas estruturas são pequenas demais para gerar qualquer interesse escuso. Pelo fato de ser distribuído, também reduz enormemente a possibilidade de um “apagão” generalizado pois cada servidor XMPP é independente.

    Facilitando o ingresso de novos usuários

    Por fim, quero deixar algumas dicas pessoais sobre como melhorar a jornada de ingresso de novos usuários no ecossistema XMPP.

    • Evite o “hoping”: pelo fato de haver muitos clientes disponíveis para uso, você pode até ficar testando esses clientes todos para você, mas evite ficar indicando mil opções para usuários novatos.
    • Eleja 1 cliente para Android, 1 para iOS, 1 para Windows, 1 para Linux e 1 para macOS e indique sempre esses para seus contatos – de preferência indique os aplicativos que são referência.

      Pessoalmente eu indico:
      – isaCloud para Android – baseado no Conversations
      – Gajim para Windows e Linux
      – Monal para iOS, ipadOS e macOS
    • Evite dar detalhes técnicos sobre o protocolo porque as pessoas não querem saber sobre isso. Você acha que elas sabem alguma coisa do WhatsApp ou do Telegram?
    • Não explique sobre criptografia a menos que perguntem diretamente a você.

    E, por fim…

    Não tente convencer alguém de que a Zeta (nome fictício) é uma empresa vilã e por isso essa pessoa deve sair imediatamente do mensageiro da empresa… aborde seus familiares ou amigos com a ideia de que eles podem deixar o mensageiro padrão pras questões de trabalho e de “resolver problemas” e usar o isaCloud – ou outro serviço XMPP – para conversar com as pessoas que são mais importantes para elas. ☺️

    Pela atenção, obrigada!
    Isadora



    —
    Links:
    https://isacloud.im
    https://xmpp.org
    https://conversations.im

  • Mais uma ampliação de estrutura

    Há alguns dias subi mais um servidor no “farm” do isaCloud. Eu havia contratado uma instância de computação na Scaleway para isolar o monitoramento da infraestrutura do datacenter primário e vinha funcionando bem… porém, como a gente sempre quer “subir mais uma coisinha”, o pequeno servidor de 1vcpu e 1GB para monitoramento rapidamente ficou pequeno demais.

    Conversando com o Kari`boka do xmpp.eco.br, subi uma nova instância de computação no Contabo. Recursos de sobra para realizar o monitoramento da estrutura e também mandar para lá algumas coisinhas que estavam num raspberry pi em casa – coisas acessórias, de monitoramento interno de casa, aplicação para fediverso e tal.

    Com esse novo servidor vou realocar também a questão da replicação do isaCloud [Messenger], para manter o funcionamento de failover dele na Contabo.

    Curiosidade: minha amiga (leiga em assuntos de tecnologia) me disse: “guria, daqui um pouco tu vai ter que ter um servidor [risos]” e eu respondi: “mas eu já estou com três!” 😁

    E uma outra pessoa me falou “tem que começar a monetizar, né? o isaCloud é top demais!” e eu respondi prontamente: o isaCloud não será monetizado porque eu já me sinto recompensada por porporcionar algo tão legal pras pessoas que eu gosto 💜

  • Alta disponibilidade acessível

    Venho há algumas semanas organizando uma forma de ter alta disponibilidade para o serviço isaCloud. É claro que o conceito de alta disponibilidade precisa ser de acordo com as demandas do “negócio” (entre aspas porque isaCloud é um serviço sem fins comerciais).

    O que eu tenho pensado:

    • Ter um cold site, isto é, um segundo datacenter (ou site secundário) com dados replicados que possa assumir o serviço
    • Não preciso ter failover automático
    • O chaveamento dos sites pode tolerar uma mudança e propagação de DNS (até 1h, digamos)

    Comecei configurando um simples lsync entre o datacenter A e o datacenter B. Estou há duas semanas mantendo essa replicação ativa de dados e configurações entre um servidor no Brasil e um na Holanda.

    Eu testei a virada de DNS de um dos domínios que tenho no isaCloud e a seguir compartilho o que funcionou e o que não funcionou:

    ✅ Consistência do histórico de mensagens
    ✅ Baixa latência para replicação
    ✅ Configurações do servidor e certificados
    ✅ Boot do serviço
    ✅ Reconexão de conversas com usuários de servidores externos
    🔴 Reconexão de conversas com usuários de outros domínios também do isaCloud

    Como mencionei ali em cima, eu virei apenas 1 domínio dos 5 que tenho no isaCloud e, nesse caso, a comunicação entre o domínio “migrado” pro site secundário e os demais que ficaram no site primário não funcionou bem porque os domínios que ficaram achavam ainda que o domínio em questão ainda era servido pelo site primário.

    Outra questão que não ficou clara para mim é sobre deixar previamente configuradas entradas de DNS SRV com menor prioridade para que a escolha pelo site secundário fosse automática. Mas isso tem uns poréns:

    • Pro meu teste não funcionou porque o site primário continuava acessível no target da entrada SRV já que os demais domínios seguiam funcionando lá
    • No caso de um failover automático pro site secundário através dessa entrada SRV com prioridade menor, o failback acabaria acontecendo automaticamente se o site primário voltasse a responder sozinho – porém os dados no site primário estariam desatualizados.

    Bem, ainda tô desenhando a melhor forma de fazer isso tudo:

    • Failover automático com faiback manual
    • Failover manual alterando o hostname pra onde os SRV apontam

    Num próximo post eu compartilho o que ficou decidido e como ficou implementado.

    Com carinho,
    Isadora.

  • Como eu cheguei no Lua

    Foi sorte… de verdade.

    Quando comecei a pesquisar sobre XMPP depois de ANOS afastada desse protocolo tão legal, me deparei com uma lista de servidores XMPP no site da XSF (https://xmpp.org).

    Eu tinha a lembrança nítida do Openfire, um dos servidores mais clássicos e padrões desde 2003 pelo menos.

    Mas eu queria recomeçar meu contato com o ecossistema. Olhei vários nomes de servidores na lista até que um deles me chamou atenção: Prosody. Ali indicava ser feito em Lua e eu pensei: “deve ser leve, acho que merece ser estudado”.

    Entrei na documentação, no repositório, olhei, olhei… parecia simples de implementar. E assim foi.

    Comecei a me debruçar sobre o Prosody, preparar container para implantação, comecei a conhecer o código fonte, a modularização, a lista enorme de módulos de comunidade e fiquei apaixonada: é isso!

    Cheguei num ponto em que já escrevi alguns pequenos módulos e modifiquei o comportamento de alguns componentes core para que a jornada de novos usuaŕios no isaCloud fosse mais amigável.

    Não me arrependo! Estou super satisfeita depois de quase 8 meses de uso, sem reclamações.

    Ter contato com os desenvolvedores diretamente por um canal XMPP também dá muita confiança de que resolver problemas não é um caminho tão árduo.

    Fico feliz de hoje estar tão confortável a ponto de poder ajudar mais pessoas que estão na jornada do Prosody.