Como funcionam as regiões no MeshCore

e por que o Brasil precisa começar a aprender sobre elas agora

(baseado no artigo australiano MeshCore Regions: What They Are, How They Work, and Why They Matter por Josh Mesilane – VK2MES)

A comunidade MeshCore no Brasil está crescendo, e com ela vem a mesma conversa que já aconteceu na Austrália, no Reino Unido, na Holanda e nos Estados Unidos: o que são regiões, para que servem e como usá-las corretamente. A funcionalidade existe no firmware há um bom tempo, mas continua sendo daquelas que todo mundo meio que sabe que existe, sem entender bem o suficiente para usar com confiança.

Mas antes de falar de regiões, precisamos falar do problema que elas resolvem.

O problema do flood sem âmbito regional

O problema é consequência direta da forma como o MeshCore foi projetado. Isso não é uma crítica, é apenas física. Em uma malha sem regiões, todo tráfego por inundação viaja pela rede completamente sem qualquer âmbito. Não há fronteira nenhuma. Ele alcança todo mundo, em toda a malha.

Para uma malha pequena e local, é exatamente o que você quer. Todo mundo ouve tudo. Perfeito.

O problema aparece quando a malha cresce. Pegue aquele tráfego de flood sem âmbito — as mensagens de teste no canal público, adverts mal configurados disparando a cada poucos minutos, pacotes de wardriving do MashMapper no modo híbrido — e deixe tudo isso se propagar por uma malha que agora se estende por centenas ou milhares de quilômetros sem convite. O tempo de ar satura. A malha fica inutilizável.

Isso não é um problema teórico. Já foi observado em várias das grandes malhas internacionais. A malha vira vítima do próprio crescimento.

Felizmente, existe uma solução: ambitos regionais.

O que são âmbitos regionais (region scopes)

Uma região é uma forma de criar uma sub-malha dentro da malha maior; um jeito de conter determinado tráfego em uma área definida e impedir que ele vaze para a rede mais ampla. Pense nela como um grupo de bairro que fica no bairro. Os operadores de Campinas podem conversar em paz no canal regional sem que todo o Sudeste fique sabendo. Um canal comunitário local pode ser genuinamente local, sem inundar a malha do país inteiro com o debate sobre o helicóptero que ficou sobrevoando o seu quarteirão.

Regiões também dão aos repetidores a capacidade de permitir ou negar mensagens com códigos de região específicos em seus equipamentos.

Como funcionam os âmbitos regionais

Aqui é onde a coisa fica interessante e onde mora a maior parte da confusão.

Quando o usuário e seu companion aplica uma região a uma mensagem para ser enviada, um código de transporte (transport code) é embutido no cabeçalho do pacote MeshCore. Pense nele como um pequeno carimbo criptográfico que o pacote carrega no ar. É esse código que as repetidoras inspecionam para decidir se encaminham o pacote ou não.

Exemplo: um companion enviou uma mensagem com o código de transporte br-sp no canal público, com a intenção de que o público alvo de sua mensagem seja todo o estado de São Paulo. Se a região br-sp foi definida no repetidor e permitida (allowed), o repetidor encaminha a mensagem. Caso a região br-sp esteja configurada como negada (denied), ou não está definida no repetidor, o pacote é descartado.

Nota: A região não influencia o roteamento. Ela não determina como um pacote viaja pela malha. Ela apenas determina se o pacote é encaminhado, com base no reconhecimento (ou não) do seu código de região pelas repetidoras no caminho.

⚠️ Atenção: o nome da região precisa ser exato

Um único erro de digitação gera um hash SHA256 completamente diferente, uma chave diferente e, portanto, transport codes que nunca vão bater com uma repetidora configurada corretamente. Seu tráfego será descartado em silêncio. Sem erro, sem aviso. Ele simplesmente para. br-sp e BR-SP são regiões diferentes que nunca se falarão.

Uma palavra sobre o “*” (ou tráfego sem âmbito)

Você vai ver o * no aplicativo e na documentação, e ele gera muita confusão porque parece um curinga, como se significasse “repita qualquer coisa”. Não é isso.

O próprio desenvolvedor líder do firmware, Scott Powell, já reconheceu publicamente que chamá-lo de * foi um erro de nomenclatura. Para todos os efeitos, leia-o como sem âmbito de região — tráfego que não tem região nenhuma aplicada. É assim que a rede se comporta hoje sem nenhuma configuração de região: tudo vai a todo lugar.

Quando a malha estiver pronta e assim o desejar, os operadores podem configurar as repetidoras para negar o tráfego sem âmbito (*) — na prática, exigindo que todo pacote de flood carregue uma região explícita. É esse o interruptor que desliga o problema do flood de vez. Mas há uma consideração importante antes de fazer isso, que veremos adiante. Não é algo para se ligar da noite para o dia.

Como usar os âmbitos de região na prática

As definições de regiões têm dois lados: o lado da repetidora e o lado do usuário. Os dois precisam estar configurados corretamente e coordenados entre si.

Antes do passo-a-passo, vale esclarecer algumas coisas que geram confusão genuína:

Repetidoras não enxergam canais. Uma repetidora não tem noção de qual canal uma mensagem pertence. O que ela vê é um pacote com hash (derivado a partir do nome do canal) e um código de transporte no cabeçalho. Se o código bate com uma região configurada, ela encaminha. Se não bate, descarta. Ponto final. Canal é um conceito organizacional do lado do usuário e completamente invisível para a lógica de encaminhamento no repetidor.

Definir uma região em um canal no aplicativo faz as mensagens enviadas por você, naquele canal, saírem do seu dispositivo automaticamente com o código de transporte daquela região. Essa é a conexão entre canais e regiões do ponto de vista do usuário. A região não é aplicada ao canal em si, mas aplicada aos pacotes que o app envia quando você está naquele canal.

O companion sempre ouve tudo o que a repetidora encaminha. O âmbito regional não filtra o que você recebe, só controla o que você envia. Se a sua repetidora encaminhou um pacote, o seu companion o recebe, independente do escopo com que ele foi enviado. Regiões limitam a propagação do seu tráfego de saída, não silenciam seletivamente o tráfego de entrada.

As regiões de uma repetidora devem refletir a área de cobertura real dela. Não há benefício (mas potencial de confusão) em configurar em uma repetidora uma região geograficamente fora da área que ela cobre. Uma repetidora em Porto Alegre só repete o que consegue ouvir. Se o tráfego de br-sp (Estado de São Paulo) nunca chega até ela pelo rádio, não faz sentido ela ter br-sp configurado.

Passo um: os operadores combinam os nomes das regiões

Esse é o alicerce de tudo. Antes de qualquer coisa funcionar, os operadores de repetidoras de uma área precisam se reunir no Telegram, no canal da própria malha, num encontro presencial ou o que for, e concordar sobre:

• Quais códigos de região serão usados
• Qual área geográfica cada código cobre
• Quais repetidoras recebem quais códigos

Não existem regras rígidas do time do MeshCore sobre convenções de nomes, mas uma abordagem hierárquica é a que faz mais sentido, e já existe um bom ponto de partida: Liam Cottle, desenvolvedor do aplicativo oficial do MeshCore para iOS e Android, publicou uma ferramenta de referência que usa códigos de localização ISO 3166 como base estruturada de dois níveis. Está em regions.meshcore.nz.

Para o Brasil, os dois primeiros níveis ficam assim:

• br — Brasil inteiro
• br-sp — São Paulo
• br-rj — Rio de Janeiro
• br-mg — Minas Gerais
• etc.

Uma pergunta que surge imediatamente é: “Nunca vamos nos conectar à malha de outro país. Para que serve o br?”

A resposta é intenção deliberada. A malha no Brasil já quase cruza divisas estaduais, e mesmo que uma malha nacional totalmente interconectada não seja realidade hoje, pode vir a ser um dia. Ter o br como âmbito significa que mandar tráfego para a malha interconectada inteira exige que o usuário escolha isso de forma específica e consciente. Transforma o envio amplo em ato deliberado, não em acidente.

O prefixo br nas siglas de estado também deixa a hierarquia visualmente evidente — br-sp se lê diferente de apenas sp, e essa legibilidade importa quando o usuário está em campo tentando escolher o âmbito certo rapidamente. Sem contar as fronteiras: em cidades como Foz do Iguaçu ou Uruguaiana, uma malha brasileira conversando com repetidoras na Argentina ou no Uruguai está longe de ser fantasia.

O problema brasileiro: nossos estados são gigantes (e nossas metrópoles, densas)

E é aqui que uma hierarquia de apenas dois níveis tropeça no Brasil. O Amazonas sozinho é maior que qualquer país da Europa Ocidental. Mas o problema não é só o tamanho: São Paulo é um estado geograficamente médio com mais de 44 milhões de habitantes. Uma região br-sp configurada em todas as repetidoras paulistas cria uma área que, para efeito do problema do flood, não é significativamente diferente de mandar tudo sem âmbito regional. O problema não desaparece; só encolhe para o nível estadual, e nos estados grandes ou densos isso ainda é uma malha enorme.

A solução proposta aqui é um terceiro nível — e o Brasil tem um candidato perfeito, muito melhor do que códigos IATA ou outros indicativos: o DDD.

• br-sp-11 — Grande São Paulo
• br-sp-19 — Região de Campinas
• br-rj-21 — Grande Rio
• br-mg-31 — Grande Belo Horizonte
• br-df-61 — Distrito Federal e entorno

Os motivos para usar o DDD são difíceis de bater:

Todo mundo já sabe o seu. Não é preciso ensinar, decorar tabela nem consultar mapa. Pergunte a qualquer brasileiro qual é o DDD dele e a resposta sai na hora. Na Austrália, a comunidade adotou códigos IATA de aeroportos como terceiro nível; funciona, mas exige que o usuário saiba que Mudgee é dge. Aqui, o morador de Campinas já é do 19.

A divisão já considera densidade populacional. As áreas de DDD foram desenhadas levando em conta concentração de população e uso de telefonia: a Grande São Paulo tem um DDD só para si (11), enquanto áreas mais extensas e menos densas do interior compartilham um código cobrindo dezenas de municípios. É exatamente a granularidade que uma malha precisa: recortes menores onde há mais gente (e mais tráfego), recortes maiores onde há menos.

É mais conveniente. Definir as regiões em um nível municipal seria pouco útil, já que muitas cidades contém apenas um ou alguns operadores. Para enviar uma mensagem com âmbito a determinada região na prática, teríamos que gerenciar talvez dezenas de códigos de região em todas os repetidores pertinentes (e saber o código correto de 3 letras de cada cidade).

É do tamanho certo. A densidade populacional de cada região de DDD é adequada e facilmente comportada pelo protocolo do MeshCore sem muito esforço.

É inequívoco e estável. Diferente de nomes de “região metropolitana” ou apelidos locais que variam de pessoa para pessoa, o DDD é um número fixo, oficial, com fronteiras conhecidas.

⚠️ Atenção: o DDD é ponto de partida, não camisa de força

O terceiro nível é livre, e nada impede a comunidade de definir agrupamentos que refletem como as pessoas realmente usam a malha:

br-sp-valeparaiba — o Vale do Paraíba, agrupando comunidades ao longo do eixo Dutra

br-sc-litoral — o litoral catarinense, cruzando as áreas dos DDDs 47 e 48

Não são códigos DDD. São abreviações combinadas pela comunidade para agrupamentos lógicos de repetidoras. E está perfeitamente certo assim. O sistema não se importa com o conteúdo da string — ele só precisa que todos os envolvidos a escrevam exatamente do mesmo jeito.

Para operadores em fronteiras entre áreas de DDD ou entre estados (pense no eixo Rio–São Paulo pela Dutra, ou na divisa MG–SP), não há regra rígida sobre quais códigos configurar. Configurar os dois, escolher um, ou definir um código comunitário de fronteira. A decisão é dos operadores envolvidos.

Passo dois: configurar as repetidoras

Com a convenção de nomes acordada, os operadores configuram os equipamentos. Cada repetidora comporta até 32 códigos de região. Na prática, para o nosso exemplo paulista, entrando nas linhas de comando do gerenciamento remoto:

Repetidoras da Grande São Paulo:

region def br br-sp br-sp-11
region save

Repetidoras da região de Campinas:

region def br br-sp br-sp-19
region save

Repetidoras do Vale do Paraíba (com o código comunitário):

region def br br-sp br-sp-12|br-sp br-sp-valeparaiba
region save

Alternativamente, pode-se também clicar no botão “Gerir Regiões” do gerenciamento remoto do repetidor:

Um detalhe que pega muita gente: a hierarquia pai/filho é organizacional, não funcional. Configurar br em uma repetidora não significa que ela vai encaminhar automaticamente o tráfego de br-sp. Cada nome de região precisa estar listado explicitamente. A repetidora só encaminha um pacote quando o cálculo do HMAC encontra correspondência com uma das regiões explicitamente configuradas. A hierarquia existe para humanos entenderem a estrutura — o firmware não infere nada dela.

Isso também significa que, se uma repetidora no caminho entre São Paulo e Campinas não tiver br-sp configurado, o tráfego enviado nesse âmbito pára ali. Ele não acha caminho alternativo sozinho. É comportamento intencional, mas reforça por que a coordenação entre operadores é genuinamente importante antes de ativar o âmbito regional.

Passo três: os usuários escolhem o âmbito regional nos companions

Com as repetidoras configuradas, os usuários passam a selecionar um âmbito de região por canal no aplicativo. Quem está em Campinas e quer mandar uma mensagem que fique na região, configura o canal regional (por exemplo, #rmc) com o âmbito br-sp-19. Quer alcançar também o Vale do Paraíba? Sobe para br-sp. Estado inteiro, br-sp. Brasil inteiro — ou toda a malha interconectada —, br.

A abordagem que faz mais sentido é começar pela menor região que leva a sua mensagem aonde ela precisa chegar, e subir a partir daí se necessário. Isso exige do usuário uma postura madura e consciente sobre para onde está mandando tráfego. Um usuário que conversa apenas com as mesmas pessoas da sua região mas manda tudo para todo lugar por padrão ocupando a frequência de todos do país desnecessariamente, e é exatamente esse comportamento que as regiões existem para conter.

⚠️ Atenção: Se o tráfego for enviado com um código de região que não está configurado nas repetidoras do caminho, ele simplesmente não será repetido. Sem erro. Sem aviso. O pacote apenas para. Se você está em um lugar novo e suas mensagens não estão saindo, é possível que a região selecionada não tenha suporte local, e é exatamente para isso que serve o próximo recurso.

E se eu estiver em uma malha desconhecida?

É aqui que a ferramenta Descobrir Regiões (Discover Regions) mostra o seu valor. Ele envia uma requisição às repetidoras locais pedindo que reportem quais códigos de região têm configurados. O aplicativo reúne as respostas e apresenta o que está disponível — na prática, um cardápio dos âmbitos que realmente funcionam onde você está. A partir daí, é só escolher o âmbito adequado para o que você quer enviar.

É um recurso valioso — e, crucialmente, significa que você não precisa conhecer as convenções locais antes de chegar. Viajou de São Paulo para Florianópolis no verão? Rode o Descobrir Regiões primeiro.

Negar ou não o tráfego sem âmbito (*)

Ao criar uma regra para bloquear mensagens sem âmbitos (*) nos repetidores, os usuários deveriam a partir de então adicionar um âmbito válido a suas mensagens obrigatoriamente. Isso traz algumas vantagens à rede, como garantir que apenas aqueles que leram os manuais e configuraram corretamente seus dispositivos possam enviar mensagens. Além disso, o bloqueio de mensagens sem âmbito fariam com que cada um tivesse que pensar no alcance que querem dar a suas mensagens; para enviar uma mensagem que trafegasse por todos os repetidores da malha MeshCore Brasil, por exemplo, o usuário teria que escolher deliberadamente o âmbito br.

Contudo, ainda não se viu a necessidade de bloquear mensagens sem âmbito. A malha brasileira ainda está relativamente contida e a comunidade apenas começou a engatinhar com o conceito de âmbito de regiões. Negar mensagens sem âmbito causaria mais transtornos do que benefícios (pelo menos por agora).

Resumo dos pontos-chave

Regiões resolvem um problema real e já observado. À medida que as malhas MeshCore crescem, o flood sem âmbito vira uma ameaça concreta à usabilidade. Regiões contêm esse tráfego em áreas definidas antes que a malha se afogue no próprio ruído.

É filtragem, não roteamento. Regiões não mudam o caminho dos pacotes pela malha. Elas determinam se as repetidoras os passam adiante.

O * não é curinga. Significa sem âmbito. Tráfego sem região nenhuma. É o padrão até que regiões sejam implantadas de verdade.

A hierarquia é para humanos, não para o firmware. Relações pai/filho entre regiões são organizacionais. A repetidora só encaminha tráfego das regiões explicitamente configuradas — ela não infere nada da estrutura dos nomes.

Regiões e canais são coisas separadas. Repetidoras são cegas a canais. Elas veem um pacote com ou sem transport code. O âmbito é aplicado ao pacote pelo app do usuário no envio — não ao canal.

O companion sempre ouve tudo o que a repetidora encaminha. Regiões controlam o que você envia, não o que você recebe.

As regiões de uma repetidora devem corresponder à geografia dela. Uma repetidora só encaminha o que consegue ouvir. Configurar uma região fora da área de cobertura não serve para nada.

Antes de negar o *, toda repetidora precisa de região padrão. O tráfego de gerenciamento — adverts, logins, CLI remota — depende de flood. Não negue o * em nenhuma repetidora antes de todas terem região padrão configurada.

A coordenação entre operadores é a parte difícil. A implementação técnica é sólida. Fazer um grupo descentralizado de operadores independentes concordar com uma convenção de nomes e configurar tudo de forma consistente — esse é o trabalho de verdade. No Brasil, temos a sorte de já ter um terceiro nível pronto, familiar e que respeita a densidade populacional: o DDD.

A adoção dos âmbitos regionais não precisa ser da noite para o dia. Não é necessário (e nem recomendável) desabilitar o encaminhamento de mensagens sem âmbito. Por hora, basta criar as definições de região nos repetidores os quais você é responsável e deixar que os usuários decidam quando utilizá-los. Se no futuro houver a necessidade de desabilitar o tráfego de mensagens sem escopo, pelo menos as regiões já estarão definidas.

Regiões são uma das funcionalidades mais sofisticadas que o MeshCore desenvolveu, e são genuinamente importantes para a saúde de longo prazo de malhas de grande escala. Quanto mais gente entender como elas funcionam, melhor posicionados estaremos para implantá-las direito no Brasil — e evitar o problema do flood sem âmbito antes que ele vire o nosso problema.

Referências e leitura complementar

• Region Filtering — MeshCore Blog — post oficial de Scott Powell anunciando a filtragem por região, incluindo a explicação sobre a nomenclatura do * e o recurso Discover Regions.
• MeshCore Repeater & Room Server CLI Reference — documentação oficial dos comandos de CLI para configuração de regiões em repetidoras.
• regions.meshcore.nz — ferramenta de Liam Cottle para geração de códigos de região com base no ISO 3166, base dos dois primeiros níveis (br / br-sp).
• MeshCore Regions: What They Are, How They Work, and Why They Matter — Zindello Industries — artigo australiano que inspirou a estrutura deste texto, incluindo a proposta de hierarquia em três níveis.