Estado da Rede Contacto

Comparativo de Projetos Mesh

Analise as diferenças entre Meshtastic, MeshCore, Reticulum e MeshCom. Comparação detalhada com critérios técnicos e fontes.

cumpre/verdade não cumpre/não é o foco
Critério
Meshtastic
MeshCore
Reticulum
MeshCom
Topologia mesh “pura” (não-hierárquica)
Se qualquer nó pode encaminhar pacotes sem papéis fixos.
Malha não-hierárquica com managed flood; qualquer nó pode atuar como relay.
Não é malha “pura”. Encaminhamento concentrado em repetidores; clientes não repetem.
Stack descentralizado multi-hop com autodiscovery e políticas flexíveis.
Usa formato tipo APRS/AX.25 com MAX-HOP e campo Digipeater; qualquer nó pode atuar como digipeater/encaminhador, além de gateways para rede de mensagens/HAMNET.
Clientes repetem/encaminham
Se um dispositivo “cliente” também pode atuar como nó de retransmissão.
Perfis permitem retransmissão (Client/Router/Repeater). A versão 2.6 introduz next-hop para DMs, aprendendo o melhor relé e reduzindo airtime.
Clientes não retransmitem. Apenas repetidores fazem encaminhamento, impondo hierarquia e exigindo planeamento da rede.
Qualquer nó pode rotear, consoante políticas e ligações ativas; o desenho do stack favorece multi-salto descentralizado.
Suporta digipeating via protocolo (campo de caminho e MAX-HOP), não exigindo funções separadas de “repetidor” para encaminhar.
Criptografia documentada (algoritmo/modo)
Indica se o projeto especifica claramente as cifras e modos de operação.
Payload cifrado com AES-256-CTR, cabeçalho em claro para permitir retransmissão. Documentação oficial descreve o esquema e gestão de chaves.
Criptografia existe (ex.: DMs e salas), mas não há documentação técnica detalhada sobre algoritmo/modo; dependência de posts comunitários e wiki incompleta.
E2EE completo com forward secrecy e ACKs autenticados; manual detalha cifras, derivação de chaves e mecanismos de segurança.
Sem E2EE documentado. Protocolo baseado em APRS/AX.25, tipicamente sem encriptação por regulamentos de rádio amador; site/protocolo não descrevem cifragem ponta-a-ponta.
Store-and-Forward / histórico
Capacidade de guardar e reenviar mensagens até entrega ou timeout.
Implementa retransmissão fiável com ACK/TTL: nós mantêm a mensagem até entrega ou expiração. Funciona bem em micro-comunidades; em redes nacionais densas pode causar congestionamento, pois cada rádio mantém filas à espera de ACK.
Usa Room Server dedicado que armazena histórico (p.ex. últimas ~16 mensagens) e reenvia a novos clientes.
LXMF com Distribution Net e E2EE: entrega diferida assíncrona, mesmo com nós offline; histórico gerido pelo protocolo.
Suporta gateways/servidor, “Unified messaging” (APRS↔MeshCom) e Mailbox (BBS) — soluções de histórico/entrega diferida via servidor.
Telemetria (tipos, cadência e desativação)
Métricas suportadas, intervalos configuráveis e forma de desligar/limitar.
Inclui um módulo de telemetria que envia dados como nível de bateria, utilização do canal e estado do dispositivo, bem como informações ambientais. A frequência de envio pode ser ajustada conforme necessário e, se preferir, é possível reduzir ou desligar esses envios.
Sem módulo de telemetria documentado comparável ao Meshtastic. A documentação pública foca Repeater/Room Server e operação via CLI/serial; não descreve claramente tipos/cadência de telemetria nem como desativar a nível de protocolo. Pode exigir soluções específicas por firmware/app.
Telemetria é ao nível da aplicação (ex.: LXMF/Sideband): pode embutir telemetria nas mensagens e fazer store-and-forward. Cadência e desligar/ativar são definidos pela app/serviço (não pelo stack).
Telemetria rica (BME/BMP/INA/DS18B20, etc.), compilação dinâmica, envio para APRS.fi; comandos para ativar/desativar sensores e definir intervalos.
Entrega de Mensagens (confirmação)
Indica se há feedback ao utilizador sobre envio e entrega de mensagens.
Apps Android e iOS mostram estados como enviado e entregue, suportados por ACKs no protocolo para confirmar a entrega ponto-a-ponto.
Apps móveis também exibem indicadores de envio/entrega, embora a confirmação seja baseada na topologia e funcionalidades atuais da aplicação.
Suporte a ACKs autenticados no core e apps LXMF/Sideband mostram estados detalhados (enviado, confirmado, entregue).
Sem ACK E2E documentado no RF; apps mostram estado, e o servidor pode reenviar/entregar (ex.: BBS), mas não há especificação de confirmação RF ponto-a-ponto.
Escalabilidade em redes densas (airtime/colisões)
Capacidade de lidar com muitos nós sem saturar o canal de rádio.
O modelo de broadcast/flood pode causar congestionamento e colisões em redes muito densas. A versão 2.6 introduz next-hop para DMs, mitigando parte do problema.
Como os clientes não retransmitem, o tráfego é concentrado em repetidores, reduzindo colisões. Exige planeamento de rede para bom desempenho.
Projetado para operar em cenários de baixa largura de banda e alta latência, com protocolos eficientes para reduzir colisões e suportar redes densas.
Multi-hop com MAX-HOP e filtragem por grupos; uso de gateways e BBS pode reduzir carga RF em redes grandes.
Resiliência em emergências (off-grid & redundância)
Capacidade de manter comunicações durante apagões ou falhas de Internet, usando energia autónoma e mecanismos locais.
Comunicação 100% off-grid via LoRa multi-hop. MQTT é opcional e serve apenas como extra para integração com redes IP (ex: apps, mapas, etc...); a rede LoRa funciona autonomamente mesmo sem MQTT.
Funciona off-grid com repetidores autónomos a painéis solares, como relatado em vários casos práticos. Contudo, a arquitetura híbrida depende de repetidores fixos: clientes não roteiam, logo a cobertura exige planeamento. Não possui um backend MQTT nativo oficial; comunicação é apenas LoRa.
Concebido para resiliência máxima: opera sobre LoRa, rádio, IP ou qualquer meio disponível. Funciona totalmente off-grid, com suporte a energia autónoma, e protocolos de store-and-forward (LXMF) para nós offline.
LoRa off-grid; pode ligar-se via gateways a HAMNET/Internet para redundância entre malhas.
Modelo de licenciamento / custos
Indica se o projeto é totalmente open-source ou se há recursos pagos/freemium.
Totalmente open-source, sem funcionalidades pagas ou camadas freemium. Licença permissiva, comunidade ativa.
OSS Gratuito
Possui funcionalidades premium (ex.: alguns Firmwares de Rádios) com licença paga. O core é gratuito, mas extras exigem pagamento.
Freemium Premium features
Projeto 100% open-source, sem camadas pagas, orientado para privacidade e liberdade do utilizador.
OSS Gratuito
Open-source (firmware e apps públicos); sem referências a funcionalidades pagas.
OSS Gratuito
Interoperabilidade entre projetos
Capacidade de comunicar diretamente, no ar, sem gateways/conversores.
Não interoperável nativamente com MeshCore. Pilha de protocolo, framing e esquema de encriptação próprios do Meshtastic.
Também não fala com Meshtastic. Utiliza formatos e papéis próprios (Repeater/Room), não compatíveis com a malha do Meshtastic.
Ecossistema separado (Reticulum/LXMF). Define a sua própria camada de rede e mensagens; não é interoperável over-the-air com Meshtastic/MeshCore.
Protocolo próprio (APRS/AX.25-like). Interliga com APRS/HAMNET via gateways, mas não com Meshtastic/MeshCore/Reticulum no ar.
Papéis/firmware (flexibilidade de configuração)
Como cada projeto lida com funções de nó e se exige firmwares distintos.
Um único firmware com perfis ajustáveis (Client, Router, Repeater), configuráveis via app oficial ou CLI.
Funções separadas por firmware: Repeater, Terminal Chat e Room Server têm builds próprios, exigindo flash diferente para cada papel ⇒ menos flexível.
O stack Reticulum define papel dinâmico por nó e por ligação, sem dependência de firmwares específicos.
Um único firmware pode atuar como cliente ou gateway; apenas RAK com ETH tem firmware próprio de gateway.
Dimensão da comunidade/adoção
Tamanho e atividade da comunidade, presença de documentação e integrações.
Comunidade ampla e ativa, com diversas integrações (apps, mapas, gateways) e documentação abundante.
Comunidade significativamente menor, com menos guias/artigos e adoção limitada a alguns países.
Comunidade com um nicho mais técnico, focada em privacidade e entusiastas de redes; não é massiva.
Comunidade radioamadora ativa (site, fórum, groups.io, apps Android/iOS), embora menor que Meshtastic.
Suporte a mobilidade (nós em movimento)
Capacidade da rede de lidar com dispositivos em deslocamento (carros, expedições, etc.).
Funciona bem com nós móveis, graças ao flood control e ao next-hop para DMs introduzido na 2.6. Ideal para expedições, hiking ou veículos.
Modelo de rede favorece repetidores fixos; clientes em movimento não roteiam, limitando flexibilidade em cenários dinâmicos.
Projetado para ambientes adversos e mobilidade variável. Stack suporta mudanças de topologia e links intermitentes sem reconfiguração.
Inclui SmartBeaconing, GPS e telemetria móveis; mensagens via RF e via gateway conforme necessário.
Ferramentas & Operação (CLI/Apps)
Disponibilidade de aplicações oficiais e comunitárias, e facilidade de configuração.
Apps oficiais e comunitárias para Android, iOS e Web, além de CLI completa para configuração e operação.
Configuração limitada via CLI/serial; apps próprias menos maduras. Exige firmwares distintos para cada papel (Repeater, Room Server, etc.).
Ecossistema rico: Sideband, NomadNet, MeshChat (LXMF) e outras ferramentas; integração fácil com CLI e APIs.
Apps Android/iOS, Web-installer, WebService, OTA e interface UDP JSON; comandos de nó via APP/serial.
Ritmo de releases / suporte a boards
Atualizações de firmware e variedade de hardware suportado.
Evolução contínua no GitHub e suporte amplo a boards ESP32, Heltec, LilyGO, etc.
Releases ativas, com suporte a T-Lora C6, RP2040, Heltec V3 e outros; foco em placas populares.
Independente de hardware: funciona em qualquer HW comum (LoRa, serial, rádio, IP), com suporte flexível via drivers.
Firmware 4.x em evolução; Web-installer; suporte a Heltec/T-Deck/RAK/ESP32, OTA e imagens dedicadas (RAK gateway ETH).
Densidade pública / rede espontânea
Presença de nós públicos e facilidade de formar redes ad-hoc sem planeamento prévio.
Grande número de nós públicos em várias regiões, permitindo formação espontânea de malhas e roaming comunitário.
Menor densidade espontânea; crescimento mais local ou país-específico. Requer planeamento e repetidores fixos para boa cobertura.
Pode operar tanto em topologias espontâneas como em redes planificadas; stack suporta auto-descoberta e ligações intermitentes.
Rede comunitária ham crescente (nós, gateways e servidores mapeados; integração APRS/HAMNET incentiva densidade regional).

Fontes

Meshtastic
MeshCore
Reticulum
  • Manual — E2EE, Fwd secrecy, ACKs, tolerância a latências. Manual (PDF)
  • LXMF / Distribution Net — FAQ
MeshCom

Notas: MeshCom é orientado a radioamadores (APRS/HAMNET). Em muitos paises, a criptografia não é permitida nas bandas de amador; o site MeshCom não documenta E2EE no RF.
Algumas fontes são documentação oficial; outras são artigos de terceiros e discussões comunitárias (identificadas como tal) — incluídas para registar comportamentos observados e limitações práticas reportadas.

Casos de uso recomendados (resumo)

Meshtastic

Off-grid Equipas móveis
Expedições, redes comunitárias, emergência.

MeshCore

Rede planeada Repetidores fixos
Bairros/eventos com repetidores dedicados e rooms.

Reticulum

Resiliência Entrega diferida
E2EE extremo, LXMF, tolerante a latência.

MeshCom

APRS/HAMNET Gateways/BBS
Redes ham integradas, telemetria APRS.fi, mailbox via servidor.