3 min de leitura ·

🔐 Crom-Nodus: Sistema de Comunicação P2P Descentralizado

O Nodus, é um sistema de comunicação P2P (peer-to-peer) descentralizado com criptografia de ponta a ponta (E2E). A maior parte do código foi acelerada com IA.

Bora testar? 🚀

O Que é o Nodus e Por Que Ele Existe?

O Nodus foi criado para resolver problemas de privacidade e controle que a maioria dos mensageiros populares não resolve:

🚫 Sem Registro: Não exige telefone ou e-mail para criar uma conta. Sua identidade e chaves criptográficas são geradas e ficam 100% no seu dispositivo.
🧑‍💻 Controle Total: Você pode hospedar seu próprio servidor relay se quiser.
🌐 Open Source: É 100% open source para que qualquer um possa auditar o código.
🛠️ Foco em Devs: Possui uma API/SDK completa para integração e uma CLI robusta para quem prefere o terminal.

✨ Recursos e Segurança

Identidade e Criptografia: Usa padrões de segurança de ponta:
- Identidade: Ed25519
- Encriptação: XSalsa20-Poly1305
- Troca de Chaves: X25519
Funcionalidades: Suporte a grupos e mensagens offline (modo none).

📊 Comparativo com Outros Serviços

Feature	Nodus	Signal	Telegram	WhatsApp	Matrix
Descentralizado	✅	❌	❌	❌	✅
Sem Registro (Telefone/Email)	✅	❌	❌	❌	❌
Self-host	✅	❌	❌	❌	✅
Criptografia E2E	✅	✅	⚠️	✅	✅
Open Source	✅	✅	❌	❌	✅
API/SDK	✅	❌	✅	❌	✅
CLI	✅	❌	❌	❌	❌

🧪 Servidor Público para Testes

Disponibilizei um servidor relay público para quem quiser começar a testar:

nodus.crom.run

⚠️ Atenção: O servidor tem rate limit configurado e está sendo bancado do meu bolso. Use-o para brincar, testar e me ajudar a encontrar bugs!

🛠️ Tecnologias e Arquitetura do Nodus

💻 Stack Principal

O Nodus foi construído com tecnologias focadas em desempenho, confiabilidade e portabilidade:

Tecnologia	Uso	Por quê?
TypeScript	Todo o projeto	Tipagem forte resulta em menos bugs e melhor manutenção.
Node.js 18+	Runtime	Suporte a `async` nativo, WebSockets e um ecossistema rico e maduro.
SQLite	Banco local	Configuração zero, leve, e garante que os dados permaneçam no dispositivo do usuário.
WebSocket	Comunicação real-time	Baixa latência e conexão persistente para troca instantânea de mensagens.
Express	API HTTP do daemon	Framework simples e maduro para gerenciar a API do processo em background.

🔐 Criptografia (Powered by TweetNaCl)

A segurança do Nodus é baseada em algoritmos criptográficos modernos e auditados, os mesmos usados em soluções de ponta como Signal e Tor.

Algoritmo	Uso	Por quê?
Ed25519	Identidade/Assinaturas	Padrão moderno, compacto e rápido para geração de identidade e garantia de autenticidade.
X25519	Troca de chaves	Garante um Key Exchange seguro e eficiente, essencial para a criptografia E2E.
XSalsa20-Poly1305	Encriptação de mensagens	Criptografia AEAD (Authenticated Encryption with Associated Data) robusta e amplamente utilizada.

🏗️ Arquitetura Modular

O projeto é dividido em módulos para garantir separação de responsabilidades e fácil manutenção:

@nodus/core $\rightarrow$ Contém toda a lógica central: criptografia, gerenciamento de mensagens e grupos.
@nodus/daemon $\rightarrow$ O processo em background que executa a lógica e expõe a API HTTP local.
@nodus/server $\rightarrow$ O servidor relay — ele é propositalmente burro (apenas repassa pacotes, não lê o conteúdo).
@nodus/cli $\rightarrow$ Permite interagir com o Nodus via comandos de terminal.

✅ Por Que o Nodus Funciona de Forma Segura?

Separação Total: O servidor relay só encaminha pacotes cifrados e não tem acesso ao conteúdo das mensagens, garantindo a privacidade.
Chaves Locais: As chaves de criptografia são geradas no dispositivo do usuário e nunca saem dele.
Zero Registro: Sua identidade é simplesmente um par de chaves Ed25519, eliminando a necessidade de e-mail ou telefone.
Resiliência: A fila de mensagens garante que, se um peer estiver offline, a mensagem será entregue assim que ele reconectar.
Qualidade Assegurada: Mais de 50 testes unitários e 7 testes E2E robustos garantem a estabilidade do sistema.

🤝 Venha Contribuir!

O projeto é robusto: Testes E2E estão passando (7/7), temos 50+ testes unitários e a documentação está completa.

Se você está interessado em testar, reportar bugs, sugerir melhorias ou contribuir com código, seu feedback é super bem-vindo!

Código no GitHub: github.com/MrJc01/crom-nodus

Para começar: npm install && npm run dev

Fonte: https://github.com/MrJc01/crom-nodus/

ronald

2 dias atrás

Cara, que projeto interessante. Gostei especialmente da separação entre daemon, core e server, porque isso deixa claro que o relay não precisa confiar em absolutamente nada além da entrega dos pacotes.

Fiquei com uma dúvida técnica sobre o modelo de segurança. Como o servidor é totalmente cego ao conteúdo e as chaves nunca saem do dispositivo, como vocês estão lidando com o problema clássico de descoberta de peers e replay prevention em uma rede P2P desse tipo? Existe algum mecanismo de verificação temporal ou assinatura complementar que mitigate tentativas de replay caso alguém capture tráfego do relay?

Pergunto porque já brinquei com libs baseadas em NaCl e sempre acabei caindo nessa mesma discussão. Curioso para entender como vocês abordaram esse ponto. Excelente trabalho.

MrJ

Autor

2 dias atrás

Valeu pelo feedback! Como o Nodus trata essas duas questões:

Prevenção de Replay

O XSalsa20-Poly1305 (via TweetNaCl) usa um nonce único de 24 bytes gerado aleatoriamente para cada mensagem. Cada payload também carrega um timestamp e um messageId único (gerado por CryptoManager.generateMessageId()).

A estrutura de uma mensagem encriptada é a seguinte:

{
  ciphertext: string,      // Conteúdo cifrado
  nonce: string,           // 24 bytes único por mensagem
  senderPublicKey: string
}

Além disso, cada mensagem é assinada com Ed25519 antes de ser enviada. O receptor:

Verifica a assinatura digital
Decripta usando sua chave X25519 derivada
Recebe o payload com timestamp e messageId

Se alguém capturar tráfego e tentar replay, a mensagem até pode ser reenviada, mas o messageId pode ser checado pelo cliente para detectar duplicatas. Reconheço que a implementação atual não persiste um cache de IDs usados (o que seria o próximo passo para mitigar replay de forma mais robusta), mas o nonce único já impede que a mesma mensagem cifrada seja reaproveitada para gerar um novo "texto válido".

Descoberta de Peers

A descoberta é feita pelo servidor relay via registro autenticado:

Cliente se conecta via WebSocket
Assina um challenge com sua chave Ed25519
Servidor verifica assinatura e registra a publicKey como online

Quando você quer enviar para alguém, você já precisa conhecer a publicKey do destinatário (troca fora-de-banda, verificação pessoal, etc.)

O servidor só sabe "quem está online", não consegue relacionar identidades a pessoas reais. É um modelo similar ao que o Signal fazia antes de usar Sealed Sender — o relay sabe quem fala com quem (metadados), mas não o conteúdo.

Para melhorar ainda mais:

Cache persistente de messageId para rejeitar replays tardios
Possível implementação de janela temporal (mensagens com timestamp muito antigo são rejeitadas)
Sealed Sender para esconder até o remetente do relay

Fico muito feliz que curtiu o projeto! Se quiser contribuir com ideias ou PRs para melhorar esses pontos, tá mais que convidado. 🙏