Cara, a ideia é muito interessante. E bem enxuta sua prova de conceito. Mas se você pretende fazer isso ser um protocolo real, seria mais interessante uma documentação com os conceitos e diretrizes de implementação. Daí eu poderia fazer um cliente desse protocolo que servisse para colocar numa aplicação. Depois da uma olhada no protocolo Secure Scuttlebutt

E pra isso você precisa baixar a internet toda com o NPM 🤪

Brincadeiras a parte, isso não é só um protocolo, você fez uma implementação de um servidor (com cliente embutido, aparentemente) desse protocolo.

O protocolo em si são regras definidas para a implementação.

A propósito, isso seria mais interessante em alguma linguagem compilada, pra aí sim você distribuir um único arquivo, sem instalação de nada, sem downloads extras, e ainda fácil de verificar que é a implementação original, através de algum hash disponibilizado junto do arquivo para download.

Possivelmente Go ou Rust seriam hoje boas opções.

Este tipo de projeto é sensacional, estou muito interessado em conhecer mais sobre a necessidade que gerou ele e como pode ser aplicado em casos de uso real.

E como foi exemplificado, que para condições de catástrofe ou perca parcial de comunicação ele poderia solucionar o problema.

Vou entender melhor como ele funciona e até mesmo escrever um servidor e cliente em uma linguagem compilada como foi sugerido para deixar mais claro em minha mente.

Fiquei com uma dúvida depois de testar o CMLK.

Nos exemplos (server.js + client.js) tudo roda em cima de WebSocket, beleza. Mas quando vi a proposta de ser multi-transporte (SMS, BLE, LoRa…), não consegui imaginar como isso se aplicaria de verdade.

Tipo no caso do SMS:

a mensagem teria que virar texto (base64/CBOR?) e ser quebrada em vários pedacinhos de 160 caracteres?

quem faria esse papel de “gateway” SMS — seria um relay especial ou cada dispositivo teria que ter modem GSM próprio?

e do outro lado, como juntar e decifrar tudo de volta?

E a mesma coisa vale pro LoRa/BLE: entendi a ideia de encapsular o pacote CMLK e mandar pelo rádio, mas na prática ainda precisa de um canal de comunicação ativo.

E é aí que bateu a confusão: a proposta é funcionar quando não tem internet, mas esses transportes todos (SMS, rede celular, BLE no alcance, LoRa no range) já dependem de algum tipo de conectividade mínima. Então fiquei pensando: no cenário “sem sinal nenhum”, como isso se aplicaria? A ideia é usar relays intermitentes (tipo store-and-forward físico, quando alguém passa perto) ou alguma rede mesh/delay-tolerant?

Talvez seja só questão da PoC estar focada em WebSocket por enquanto, mas fiquei na dúvida se já existe algum protótipo real usando SMS/LoRa ou se isso ainda tá mais no campo da visão de design.

Esse tipo de projeto é bem legal. Eu fiz um parecido Bitchat versão C++: https://github.com/bitchatz/bitchatz-cpp

Parabéns.

Muito legal a iniciativa de criar e compartilhar, mas na prática, não é um problema novo, missões espaciais e dispositivos IoT de zonas rurais já convivem a muito tempo com essa situação por exemplo.
Estou longe de ser um especialista nessa área, mas em uma rápida pesquisa encontrei a RFC 9171 de 2015 da NASA (Bundle Protocol Version 7), no que o CMLK se difere em relação a este? Quais problemas ele resolve q era falhos nos outros protocolos existentes?

Amigo, meus parabéns.

Espero que apesar de não querer você tenha o reconhecimento merecido.

Achei o projeto muito interessante e fiquei pensando em como ele poderia evoluir sem perder a essência de simplicidade, resiliência e descentralização que você propõe. Uma das primeiras coisas que me veio à mente foi a experiência dos usuários finais: hoje o protocolo roda em terminal, o que é perfeito para desenvolvedores, mas para ganhar escala talvez fosse interessante criar camadas de interface — aplicativos móveis ou desktop que rodem o CMLK em segundo plano, permitindo que qualquer pessoa envie mensagens sem precisar lidar com código.

Outro ponto seria expandir os meios de transporte. Além de WebSocket e SMS, vejo muito potencial em integrar redes mesh, Bluetooth multiponto, Wi-Fi Direct ou mesmo LoRa. Isso permitiria que aparelhos próximos servissem como retransmissores, garantindo que, mesmo sem internet, a mensagem pudesse seguir adiante até alcançar o destino quando algum dispositivo se reconectasse. Esse modelo me fez pensar em sistemas P2P, como os usados para compartilhar arquivos em torrent, onde cada nó da rede contribui para o fluxo de dados. Talvez esse conceito possa fortalecer ainda mais a proposta descentralizada do CMLK.

Também imagino que separar a arquitetura em camadas possa ser uma forma de manter o núcleo do protocolo leve e sólido (criptografia, store-and-forward, identidade descentralizada), enquanto a comunidade adiciona diferentes módulos de transporte de acordo com a necessidade de cada cenário. Isso abre espaço para que outros desenvolvedores, entusiastas ou engenheiros de redes de emergência contribuam sem precisar alterar a base.

Em termos práticos, penso em um caminho em três fases: primeiro consolidar o núcleo para devs (como você já fez), depois permitir que entusiastas técnicos testem versões mais acessíveis, e por fim disponibilizar para usuários finais via aplicativos simples, escondendo toda a complexidade.

Gostaria de ouvir sua visão sobre essa evolução. Você imagina o CMLK caminhando nesse sentido de integrar modelos mesh/P2P e camadas de interface para usuários finais, ou a ideia é mantê-lo minimalista e deixar que a comunidade faça esse papel?

Você conhece os projetos BitChat e Nostr? Será que tua ideia se encaixaria no escopo desses projetos já existentes?

Achei bem interessante, em 2023 trabalhei em um projeto de estudo que usava wi-fi direct para comunicação offline em áreas sem internet, mas acabei não avançando tanto, atualmente estou estudando um pouco sobre Meshtastic, acredito que possa se encaixar bem no contexto que você quer utilizar.

Olá! Seu projeto é muito interessante. Atualmente, estou desenvolvendo um aplicativo e esse protocolo viria a cair muito bem. Minha proposta visa eliminar a dependência das operadoras, já que hoje ficamos muito presos à questão de que quase todos os aplicativos dependem do número de telefone. Se você não mantiver seu número, perde o acesso à maioria dos serviços relevantes, como WhatsApp e Telegram.

Meus 2 cents,

Parabens pela iniciativa e por compartilhar conosco !

Sempre eh positivo mergulhar em projetos como esse - seja como aprendizado ou como a busca em criar algo para a comunidade.

Focando no projeto, vamos tentar sintetizar seus objetivos:

• Criar uma metodologia de envio de mensagens assincronas baseado em uma estrutura "cliente" e "servidor", onde as mensagens nao expiram e ficam em stand-by caso do destinatario nao esteja disponivel ate que a entrega seja realizada. As mensagens podem ser apagadas pelo remetente caso desejado. Toda a comunicacao deve ser criptografada e os servidores apenas fazem o delivery da mensagem, sem interagir com seu conteudo.

OK - acho que isso meio que cobre "o que" o projeto deve fazer.

Agora vem o "como fazer".

Uma questao que se torna meio obvia eh que nao podemos ter apenas 1 servidor - afinal a ideia eh resiliencia. Entao precisamos pensar em uma forma de ter diversos servidores comunicando-se entre si. Mas estes servidores precisam ser independentes - mas seria legal se pudessem trabalhar em conjunto para a entrega das mensagens, roteando (relay) o trafego.

Alem disso tem a questao do registro: o cliente precisa ter uma identificacao unica nesta rede - mas os servidores precisam saber onde o cliente esta conectado para fazer o delivery.

Seria algo como: cliente se conecta no servidor, servidor divulga que tem este cliente, servidores ja sabem onde deve entregar a mensagem.

Legal, mas tem um problema: volume de trafego - se tivermos milhoes de clientes se conectando, ficar gerando anuncios de conexao pela rede nao eh pratico (alem do fato de que esta conexao pode cair e precisamos anunciar novamente, talvez ate sem que o primeiro anuncio tenha terminado).

Um passo atras: precisamos de uma rede de servidores descentralizados que consigam saber quais os servidores disponiveis e quando alguem conecta neles para fazer o delivery.

Mas surge uma pergunta: o delivery sera do tipo "push" ou "pull" ? Como fazer isso de forma eficiente ?

Exemplificando: o cliente se conecta, a rede de servidores detecta isso e envia as mensagens pendentes ("push") ou o cliente se conecta e sai perguntando para os servidores "voce tem algo para mim ? ("pull")·

Hummm, nenhuma das forma parece muito eficiente - temos de repensar um pouco aqui.

Uma possibilidade seria o cliente ter um servidor de preferencia/referencia - assim resolve varios problemas: nao preciso ficar fazendo o anuncio e os servidores ja sabem onde entregar a mensagem independente do cliente estar conectado.

So preciso que cliente identifique qual o servidor de preferencia - e isso poderia ser dinamico.

Hummm, eh uma ideia: um cliente com identificacao unica, que aponte seu servidor de mensagens de preferencia e que os servidores consigam entregar as mensagens entre si.

Parece fazer sentido.

Poderiamos ter 2 protocolos especificos: o protocolo entre cliente e servidor e o protocolo entre servidores - para tornar o processo mais eficiente, afinal as necessidades do delivery para o cliente sao um pouco diferentes do roteamento entre os servidores.

Hummm, poderiamos chamar este protocolo entre cliente e servidor de IMAP ou POP e o protocolo entre servidores de SMTP - parece fazer sentido.

Bricandeiras a parte - acho a ideia interessante: so precisa pensar um pouco em como diferenciar do email e aproximar de sistemas de IM.

Talvez pensar nos servidores em rede MESH ou ate algo semelhante ao um sistema de BLOCKCHAIN (TANGLE ?) para viabilizar.

Saude e Sucesso !

Boa iniciativa, porem logo o governo ira querer se apossar.