16
Ak4ai
4 min de leitura ·

Pitch: Construí um cliente de Discord nativo em Rust que usa apenas ~30MB de RAM (e 0.1% de CPU)

Fala pessoal do TabNews! 👋

Se você joga no PC ou trabalha com várias abas e ferramentas pesadas abertas ao mesmo tempo, provavelmente já passou por isso: abrir o Discord oficial só para conversar com amigos em call e ver o Gerenciador de Tarefas acusar 500MB a 800MB+ de memória RAM e picos de uso de CPU que provocam aqueles micro-stutters (micro-engasgos) chatos no meio de uma partida.

O motivo é conhecido: o Discord oficial roda sobre o Electron (Chromium + Node.js), o que significa carregar um navegador web completo em segundo plano.

Incomodado com isso, decidi encarar um desafio: é possível recriar a essência do Discord — chat de texto e canais de voz com áudio de alta fidelidade — em um binário nativo ultra-leve em Rust?

O resultado é o Litecord, um projeto 100% open source que consome menos de 35MB de RAM e < 0.1% de CPU em idle. Compartilho abaixo as decisões de arquitetura e os desafios técnicos que enfrentei.

🛠️ A Escolha da Stack: Por que não usar WebView/Tauri?

A primeira tentação seria usar Tauri (que substitui o Chromium pelo WebView do sistema). Porém, para atingir o objetivo de performance máxima e consumo irrisório de memória, decidi ir direto ao metal:

  • Linguagem: Rust (2021 Edition) — controle total de memória, zero runtime overhead e segurança para processamento de áudio concorrente em tempo real.
  • Interface Gráfica: Slint UI — um framework moderno de GUI declarativa compilada nativamente. O Slint não renderiza HTML/CSS; ele compila o layout direto para instruções gráficas nativas (via FemtoVG/OpenGL ou renderizador de software), gerando uma interface fluida a 60 FPS com menos de 10MB de pegada de memória.
  • Pipeline de Áudio: CPAL (Cross-Platform Audio Library) + decodificador nativo Opus (48kHz).
  • Async Runtime: Tokio para orquestrar WebSockets, chamadas REST da API do Discord e o loop de eventos de interface sem travar a thread principal.

🔬 Desafios Técnicos Interessantes

1. Voz em Tempo Real e Criptografia DAVE (E2EE)

O Discord recentemente começou a implementar o protocolo DAVE (MLS - RFC 9420) para criptografia de ponta a ponta nas chamadas de voz.

  • Para garantir que a voz não pipocasse ou ficasse "robótica" quando a GPU/CPU do computador estivesse em 100% de carga (durante um jogo pesado), implementamos Opus PLC (Packet Loss Concealment) com um jitter buffer adaptativo de 40ms e resampler cúbico Hermite a 48kHz.

2. Login Seguro por QR Code (Discord Remote Auth v2)

Em vez de pedir para o usuário colar tokens manualmente ou inspecionar cabeçalhos de rede:

  • O Litecord implementa o protocolo Remote Auth v2 do Discord via WebSocket com pares de chaves RSA-2048 transitórias.
  • O app gera um QR Code na tela; você escaneia pelo aplicativo do Discord no celular e autoriza o login com 1 toque.
  • No Windows, o token da sessão é persistido no disco criptografado através da API nativa Windows DPAPI (CryptProtectData), garantindo que nenhum outro processo ou usuário não autorizado no PC consiga ler o segredo.

3. Ducking de Fala Dinâmico (Foco no IGL / Líder do Squad)

Em chamadas com muitas pessoas falando ao mesmo tempo ou bots de música tocando no canal, a comunicação tática fica caótica. Criamos um sistema de Prioridade de Fala (P:1, P:2, etc.):

  • Quando o líder/shot-caller fala, o volume de todos os outros participantes e bots é atenuado suavemente em tempo real (ducking inteligente), voltando ao normal assim que ele termina a frase.

4. DeepSleep na Bandeja do Sistema

Ao minimizar o Litecord para a bandeja do sistema (System Tray):

  • Todos os loops de renderização visual e atualizações de UI do Slint são completamente suspensos (0.0% de CPU).
  • Apenas a thread assíncrona leve de recepção de áudio RTP/Opus continua ativa, consumindo recursos praticamente imperceptíveis enquanto você joga.

📊 Comparativo: Discord Oficial vs Litecord

MétricaDiscord Oficial (Electron)Litecord (Nativo em Rust)
Uso de CPU (Idle)1.5% - 4.5%< 0.1% (DeepSleep: 0.0%)
Uso de CPU (Voz Ativa)4.0% - 8.0%~0.4% - 0.8%
Uso de Memória RAM (Idle)~400 MB - 750 MB~28 MB - 35 MB
Uso de Memória RAM (Voz)~600 MB - 900 MB~32 MB - 45 MB
Tamanho do Executável~180 MB~8 MB (Standalone)
Tempo de Inicialização4 a 9 segundos< 200 milissegundos

📦 Código Aberto & Como Testar

O projeto é 100% open source sob licença MIT e já conta com executáveis prontos gerados pelo GitHub Actions:

💬 Gostaria do Feedback de Vocês!

Quais outras otimizações ou recursos essenciais vocês acham que fariam sentido manter em um cliente focado puramente em leveza e baixo consumo? Fiquem à vontade para testar, abrir issues ou mandar PRs! 🦀🚀

Carregando publicação patrocinada...
1
1

É uma ótima reflexão, Nando. O que acontece é que frameworks baseados em web (como o Electron, que o Discord oficial usa) permitem que uma empresa programe a interface gráfica uma única vez (usando HTML/CSS/JS) e ela rode em Windows, Mac, Linux e web ao mesmo tempo. Criar aplicativos nativos e super otimizados diretamente no 'metal' (como o Litecord em Rust) costuma ser muito mais difícil, exige mais tempo de desenvolvimento e conhecimento de baixo nível de cada sistema operacional. Por isso, a maioria das empresas escolhe o caminho mais rápido e barato para elas, mesmo que isso custe 800MB de RAM do nosso computador.

1
1
1

Muito obrigado, Jordão! Sim, funciona 100% com as contas normais. O sistema de login usa o protocolo oficial do Discord por QR Code. É só abrir a tela inicial do Litecord, escanear o QR code com o aplicativo do Discord no seu celular e ele faz o login automático de forma segura, sem você precisar ficar copiando e colando tokens de navegador. Depois me conta o que achou da performance no seu notebook!

1

Opa! Vi seu post e achei muito interessante, principalmente por que eu mesmo me estresso com o discord, acho o app muito pesado, tanto que muita gente que conheço prefere só usar no navegador mesmo, e resolvi testar o Litecord em uma VM. Tive uns problemas para abrir por causa do Visual C++ (vcruntime140.dll, talvez alguma falha durante o empacotamento, da pra resolver instalando visual c++ mas fica como sugestão, já que nem todo usuário comum vai saber diagnósticar diretamente) e do renderer gráfico (o programa inicia mas sem exibir tela, talvez o programa poderia cair automaticamente para software quando não encontrar um driver grafico com aceleração compativel, mas esse é um bug mais especifico e talvez só aconteceu por que rodei na VM), mas consegui fazer funcionar usando o backend por software.

Como o projeto é open source, aproveitei para dar uma olhada no código com ajuda do Codex. Ele apontou alguns pontos que talvez valha a pena revisar, principalmente no compartilhamento de tela e no tratamento de tokens/logs. Não sou da área de segurança e posso estar interpretando alguma coisa errado, então preferi não colocar os detalhes aqui publicamente (já que algumas .

Caso tenha interesse posso enviar o que achei por email ou alguma outra forma de contato, talvez pelo proprio github se ativar a opção de "Private vulnerability reporting".

De qualquer forma, projeto muito massa! Na tela de login, consome só 9mb de ram 🤯

1

Todas as suas observações foram extremamente pertinentes e já implementamos as correções na versão v0.3.8 que acabou de
sair:

  1. Empacotamento e vcruntime140.dll:
    Configuramos o Rust para compilar com CRT estático (+crt-static). Agora o .exe é 100% autossuficiente e roda
    imediatamente em qualquer Windows ou VM limpa, sem exigir a instalação manual do Visual C++ Redistributable.
  2. Fallback Automático para Software Renderer:
    Implementamos uma rotina de fallback inteligente na inicialização. Se o app detectar que a VM ou o sistema não possui
    aceleração OpenGL/GPU compatível, ele cai automaticamente e de forma transparente para o backend por software do Slint
    (SLINT_BACKEND=software) sem travar ou ficar com tela preta.
  3. Segurança de Tokens e Logs:

• Linux: Criamos um cofre criptografado em repouso com AES-256-GCM em ~/.config/litecord/session.vault com permissões
Unix restritas (0700/0600) e chave atrelada ao hardware (/etc/machine-id) + UID do usuário.
• Windows: Mantemos a proteção nativa via DPAPI da Microsoft (CryptProtectData).
• Logs: Higienizamos todos os logs para não imprimir nenhum caractere de tokens ou chaves de sessão.

  1. Compartilhamento de Tela P2P:
    A derivação de chave AES-256-GCM e os tópicos anônimos MQTT agora exigem a voice_secret_key (chave criptográfica
    exclusiva de 32 bytes emitida pela Voice Gateway do Discord ao entrar na sala). Assim, somente quem estiver autenticado
    na chamada consegue descriptografar os pacotes ou descobrir o canal.

Se quiser testar a nova versão v0.3.8, já está disponível na aba de Releases do repositório:
👉 https://github.com/Ak4ai/Litecord/releases/tag/v0.3.8

1

Excelente só espero que q ditadura não proíba de vez o Discord, realidade cada vez mais próxima. Já vai pensando num vpn embutido pro futuro 😅. Parabéns pelo projeto.

1

Muito obrigado pelo apoio! A ideia de ter suporte a proxy ou uma solução de roteamento embutida é muito pertinente pensando em resiliência e acessibilidade. Vou anotar essa sugestão no backlog do projeto para estudarmos no futuro. Valeu!

1
1

Sim, funciona perfeitamente. O Litecord se conecta exatamente à mesma infraestrutura (servidores WebSocket e de Voz) que o Discord oficial usa. Ou seja, você pode entrar em um canal de voz usando o Litecord e conversar normalmente com seus amigos que estão usando o app oficial no celular, PC ou navegador. A comunicação é totalmente transparente entre as versões!

1
0
1

Hahaha! Pois é, a gente faz o que pode para tentar salvar a nossa memória RAM enquanto joga. Um dia eles adotam o Rust de vez no desktop! 😂