Executando verificação de segurança...
1

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.

Carregando publicação patrocinada...
1

A ideia do CMLK é justamente ser independente do transporte. Hoje, na PoC, usamos WebSocket porque é o caminho mais simples para validar o protocolo, mas nada impede que ele rode em cima de outros meios como SMS, BLE ou LoRa.

Na prática, o que aconteceria:

Fragmentação: mensagens seriam serializadas (CBOR/Base64) e quebradas em pedaços do tamanho que cada transporte suporta (ex.: 160 caracteres no SMS, poucos bytes no LoRa). No destino, esses fragmentos seriam reagrupados e validados.

Gateways/Dispositivos: cada cenário pode funcionar de duas formas:
dispositivo com o hardware do transporte (modem GSM, rádio LoRa, BLE);

ou um gateway que faz a ponte (ex.: recebe via SMS e repassa pro restante da rede CMLK).

Operação sem internet: em vez de depender de conectividade contínua, o protocolo pode trabalhar de forma store-and-forward ou até em topologias mesh/DTN, onde cada nó guarda e repassa mensagens quando entra em alcance de outro.

Ou seja: mesmo em ambientes com conectividade limitada, o protocolo continua funcionando, só que com um modelo mais assíncrono. O foco atual está em WebSocket, mas a arquitetura foi pensada para suportar essas extensões de transporte conforme a necessidade.