Equipe de desenvolvimento do MeshCore se separa por disputa de marca registrada e questões com código gerado por IA
(blog.meshcore.io)- Em um projeto de rede mesh que cresceu rapidamente, problemas envolvendo o registro de marca e o uso de código gerado por IA acabaram levando à ruptura entre o core team e Andy Kirby
- Andy Kirby usou amplamente o Claude Code para expandir o trabalho até device standalone, app móvel, web flasher e ferramenta web de configuração, e a equipe afirma que uma parte considerável desse trabalho foi feita em formato de vibe coded e isso teria sido ocultado
- O estopim direto da separação foi o fato de Andy ter solicitado o registro da marca MeshCore em 29 de março sem informar a equipe; depois disso, as conversas sobre suas intenções fracassaram e a comunicação foi interrompida
- O core team definiu o MeshCore oficial como a única source of truth estabelecida pelo repositório no GitHub e segue com o desenvolvimento de firmware, releases de apps, documentação técnica e discussões de desenvolvimento tendo o meshcore.io como nova base
- Como, desde o início em janeiro de 2025, o Map oficial já garantiu mais de 38.000 nós e o App oficial mais de 100.000 usuários ativos, ficou ainda mais importante deixar claros o espaço oficial de informação e a entidade responsável pela operação
Contexto da separação
- Desde o início do projeto, a equipe de desenvolvimento do MeshCore lançou mais de 85 versões do MeshCore Companion, do Repeater e do firmware do Room Server, além de oferecer suporte a mais de 75 variações de hardware
- A equipe sempre manteve uma postura cautelosa em relação a código gerado por IA, mas Andy Kirby passou a usar amplamente o Claude Code e começou a atuar de forma independente, ampliando o escopo do trabalho por todo o ecossistema MeshCore, incluindo device standalone, app móvel, web flasher e ferramenta web de configuração
- O texto afirma que Andy Kirby ocultou da equipe que a maior parte desse trabalho havia sido feita em formato de vibe coded
- A equipe realizou uma enquete no Discord do MeshCore sobre IA e confiança, mas o texto não apresenta em forma textual os números da enquete nem resultados detalhados
- Como fator que intensificou o conflito, o texto diz que Andy solicitou em 29 de março o registro da marca MeshCore sem informar a equipe
- A equipe tentou discutir suas intenções, mas a conversa fracassou e, no momento, a comunicação com Andy está interrompida
- A equipe afirma que tentou resolver a situação nos últimos meses e que, para quem trabalhou por tanto tempo no projeto, o choque foi grande a ponto de parecer que alguém de dentro havia se aliado a robôs e advogados
MeshCore oficial
- O ponto central da disputa agora é o direito de uso da designação ‘official’, e Andy, ao afirmar fortemente que é dono da marca, vem usando ativamente essa expressão na linha MeshOS
- A equipe define o repositório no GitHub como o único MeshCore oficial
- Esse repositório funciona como a source of truth que determina o que é o MeshCore
- Andy nunca contribuiu para esse repositório
- Após a separação interna, a equipe abriu o novo site meshcore.io, e como Andy controla o meshcore.co.uk e o servidor original do Discord, quase não havia outra opção
- Depois da abertura do novo site, Andy teria usado o Claude para copiar até o look and feel, e pedidos para que isso não fosse feito não foram atendidos
Crescimento do projeto
- O MeshCore começou em janeiro de 2025 e cresceu muito rapidamente
- No momento deste texto, o MeshCore Map oficial mostra mais de 38.000 nós no mundo todo, e o MeshCore App oficial tem mais de 100.000 usuários ativos no Android e no iOS
- Quanto maior o projeto fica, mais importante se torna o espaço oficial de informação fornecido pelo core team
- Recentemente, continuou a expansão de sites do MeshCore voltados a países e comunidades regionais de mesh, com os seguintes exemplos listados diretamente
- Andy Kirby teve um papel importante na divulgação do MeshCore em seu canal pessoal no YouTube, mas agora está focado em promover seus próprios produtos
Direção operacional daqui para frente
- O core team continuará usando o meshcore.io como centro para desenvolvimento de recursos de firmware, correção de bugs, gestão de PRs e discussões entre desenvolvedores
- Os changelogs de novos releases de firmware e apps, posts de blog e documentação técnica agora serão distribuídos pelos canais abaixo
- As pessoas que participam do blog e seus papéis também foram apresentados
- Scott é o fundador do projeto e lead firmware engineer, além de também ser o desenvolvedor do firmware Ripple
- Recrof é o desenvolvedor do MeshCore Map oficial e responsável pelo Firmware Flasher, além de compartilhar insights sobre o desenvolvimento inicial do MeshCore Map
- Liam Cottle é o desenvolvedor do MeshCore App oficial e deve publicar um guia de introdução ao MeshCore App
- FDLamotte é responsável por ferramentas em Python para o MeshCore e por variações de firmware STM32
- Oltaco está à frente do novo OTA Fix bootloader, voltado a aumentar a confiabilidade das atualizações de firmware
Core team
- Atualmente, a equipe do MeshCore é formada por Scott, Liam, Recrof, FDLamotte e Oltaco
- A equipe afirma que seguirá adiante com design e desenvolvimento de alta qualidade baseados em software escrito por pessoas
Nova base
- A partir de agora, releases oficiais, documentação técnica e discussões da comunidade acontecerão tendo este novo site como centro
- Junto com o novo site, também foi iniciado um novo servidor no Discord
- Nesse espaço, será possível falar diretamente com os desenvolvedores do MeshCore, obter ajuda com o projeto e contribuir para o futuro do MeshCore
- Os canais oficiais relacionados foram organizados da seguinte forma
- Official Website: https://meshcore.io
- Latest Updates: https://blog.meshcore.io
- Technical Docs: https://docs.meshcore.io
- Official GitHub: https://github.com/meshcore-dev/MeshCore
- Reddit: https://reddit.com/r/meshcore
- Facebook: https://facebook.com/groups/meshcore
- Discord: https://meshcore.gg
1 comentários
Comentários do Hacker News
Se você ainda não experimentou, recomendo muito dar uma olhada no Reticulum
O projeto base parece precisar de novos mantenedores agora, e o desenvolvedor principal também tem posições bem fortes, mas o design da camada de protocolo de rede distribuída é realmente muito bem lapidado
O app de desktop funciona pela internet (IP) ou por conexão USB com placas LoRa existentes, e recentemente comprei um https://lilygo.cc/products/t-echo-lilygo, instalei o firmware open source e usei tanto conectado ao desktop por USB quanto por Bluetooth com o https://github.com/torlando-tech/columba, e a experiência foi excelente
Por causa desse app, o Reticulum realmente parece um cidadão de primeira classe em termos de suporte a mensagens, e embora haja limitações, também dá para enviar arquivos e imagens
Como ele opera no nível da rede, você também pode criar seu próprio app diretamente em cima do Reticulum
Acho que em algum momento as pessoas vão perceber que o LoRa simplesmente não vai conseguir atender às exigências de largura de banda e velocidade para ir além de mensagens de texto simples
Ainda assim, testei uma chamada de voz em tempo real em um único salto LoRa com Reticulum e funcionou surpreendentemente bem
O wiki para começar está aqui: https://reticulum.miraheze.org/wiki/Welcome
Para quem só quer criar um app, a experiência de desenvolvimento foi bem frustrante, e embora o conceito seja legal, há armadilhas demais que atrapalham e não parecia sustentável para fazer bootstrap
Em especial, tentei portar a stack para Rust no-std para rodar em dispositivos nrf52 LoRa e transportar pacotes do reticulum pela rede MeshCore existente, mas foi um pesadelo até para verificar se meus pacotes estavam sendo montados corretamente
Sempre só vi testbeds muito pequenos
Também me pergunto se isso realmente importa na prática
Não entendo por que os projetos mesh são tão excessivamente rígidos na aplicação de marca registrada
O Meshtastic é parecido, e um dos motivos pelos quais comecei a me interessar pelo MeshCore foi justamente ler as regras de marca do Meshtastic e achar aquilo exagerado demais
Compartilhamento livre e sem restrições não é o padrão do mundo; na verdade, está mais para exceção
Por enquanto, isso parece mais um caso de uma pessoa no Reino Unido registrando a marca sem aprovação dos outros membros da equipe, e ainda não é como se alguém estivesse de fato atacando terceiros
O MeshCore já tem mais de 100 mil usuários e repetidores brotando pelo mundo como erva daninha, então o incentivo para monetizar isso é enorme
Especialmente porque a pessoa tentando monetizar isso não era da parte de firmware ou desenvolvimento de app, e sim do marketing
Pelo visto, ele só não quer que o trabalho dele contribua para uma rede de assassinato por IA imparável
O pedido de marca registrada, se for verdade, é claramente um ato hostil e ruim, mas eu não ficaria indignado só porque alguém usou Claude Code
Eu realmente uso o MeshCore e opero vários repetidores, mas codificação assistida por IA em si não me incomoda
Ainda assim, acho que isso deve ser divulgado, especialmente se for closed source
A tentativa de tomar o ecossistema via marca registrada parece insana, e também incomoda que o Andy não tenha contribuído para o projeto no GitHub em si, só feito complementos pessoais com fins lucrativos
Ao mesmo tempo, também parece verdade que a equipe central do MeshCore tentou reforçar a narrativa adicionando um viés anti-IA
Na verdade, apoio o fato de terem levantado isso publicamente
Quem diz que revisou corretamente 1000 linhas de código mal-acabado cuspidas por IA está enganando a si mesmo ou aos outros, e provavelmente nunca fez revisão de código em larga escala de verdade
Ler 1000 linhas de texto e analisar o impacto da complexidade do código e os edge cases são coisas completamente diferentes, e uma revisão completa desse tipo pode levar dias
Só um PR de 100 linhas já pode consumir horas, mas as pessoas passam por cima com uma postura de “revisei tudo”, e eu acho que é assim que os 0-days e os vazamentos ficam cada vez mais frequentes
Por isso eu jamais confiaria em algo no estilo "You are absolutely correct, apologies for the oversight, here's a revised version:"
Mexi um pouco no MeshCore e no Meshtastic, e embora sejam divertidos, sinto que no geral são bem superestimados
O conceito em si acaba ficando meio turvo por causa do pessoal com mentalidade SHTF que entra nisso
Eu tinha interesse no uso para redes de sensores, mas a maior parte da conversa real gira em torno de gente obcecada em trocar textos estilo Hello World, enquanto parece que pouca gente enxerga quão mal essas redes funcionariam em uma situação real de SHTF
Os dois apps móveis são bem capengas, e o Meshtastic me irrita mais ainda porque parece que as equipes de UI de Android e Apple nem conversam entre si
Se as pessoas usam plataformas diferentes, fica difícil demais fazer onboarding de novos usuários ou responder perguntas
Foi barato e divertido de montar, mas eu queria ao menos uma persistência de mensagens melhor para garantir que elas não se perdessem
Mas, se minha vida dependesse disso em uma situação séria, eu ficaria bem inseguro com essa rede mesh
Ainda é instável demais para ser considerada um meio confiável, embora provavelmente ainda seja melhor do que não ter nada
A configuração dos dispositivos também é um problema: tentei instalar o ambiente de desenvolvimento completo em um raspberry pi 3 para poder trabalhar em um lugar sem internet, mas fiquei sem memória ao tentar compilar o enorme web app que é a interface principal do cliente
A falta de padronização provavelmente também prejudicaria bastante a usabilidade em uma situação real de SHTF
Por exemplo, nem está claro por que alguém deveria usar meshcore em vez de meshtastic, e numa situação dessas eu nem acho que LoRa estaria no topo das minhas prioridades
Dá para usar uma base Mikrotik com backend Chirpstack, e essa combinação já foi muito validada em ambientes comerciais
Esse app cliente ainda é closed source?
Para mim isso já seria desqualificação imediata, e não me surpreende nem um pouco que esse tipo de coisa tenha acontecido
E acho que isso nem vai parar por aqui
Agora o cliente fechado não é mais necessário
Ele também suporta MQTT, community observers, bots, webhooks etc., e comecei porque precisava de um cliente de uso cotidiano que não ficasse preso ao rádio, mas agora ele já está bem maduro como cliente complementar para usuários avançados
A API do rádio e o firmware são abertos, há muitas outras opções e às vezes elas são funcionalmente até melhores que as alternativas closed source, então não tenho grande objeção à decisão de fechar parte do software para ganhar dinheiro
https://github.com/jkingsman/Remote-Terminal-for-MeshCore
A mesh da minha região também estava testando o meshcore na semana passada, mas isso basicamente matou meu interesse
Já vi o Andy Kirby no YouTube, e os vídeos pareciam tão sensacionalistas, exagerados e caça-cliques que acabei associando a imagem dele à gestão do projeto, e foi aí que comecei a pegar antipatia pelo meshcore
Isso agora me dá a sensação de que aquela intuição estava certa
Pelo estado atual das coisas, o site .io exibe o logo “MESHCORE”, enquanto o site .co.uk mostra o logo “MESHCORE(tm)”
[1]: https://meshcore.io
[2]: https://meshcore.co.uk
Nunca usei esse projeto e não conheço ninguém envolvido
Mas acho interessante como, toda vez que alguém aparece com papo de “vou reescrever tudo com IA”, essa pessoa acaba se revelando um grande problema com frequência impressionante
Claro que talvez este caso não seja assim, e eu também não conheço todo o contexto, então não consigo dizer se esse post inteiro é confiável
Ainda assim, na minha pequena amostra, a relação sinal-ruído parece bem boa
Também sou radioamador, mas não sou do tipo que denunciaria alguém à FCC imediatamente por uma infração de regra; ainda assim, é preocupante a postura de não saber ou não se importar com o motivo de essas regras existirem
Primeiro, não tenho certeza se essa interpretação das regras está correta, mas assumindo que esteja, a maioria das outras pessoas na thread também parecia partir do pressuposto de que estava correta
Para mim, a resposta ao “estamos violando as regras e precisamos mudar” soou como “em Seattle isso é inconveniente, então não vamos mudar” e “em Boston também não funciona bem, então não dá”
Não é o tipo de coisa em que dá para agir como se as regras fossem opcionais
Pessoas que usam espectro de rádio compartilhado em geral estão obedecendo à lei, e se o projeto funciona pior quando usado legalmente, então é o projeto que precisa ser corrigido
Por esse tipo de coisa eu até entendo por que radioamadores mais velhos ficam cada vez mais sensíveis
Eu gosto de usar IA no desenvolvimento e também acho isso importante no desenvolvimento moderno
Mas existe sim uma diferença clara entre código de IA e código escrito diretamente por pessoas, então isso precisa ser divulgado
Se grandes partes do projeto foram feitas com vibe coding, também fica nebuloso se essa pessoa realmente tem o direito de concordar com o DCO e de distribuir aquilo sob a LICENSE do codebase
Já é difícil entender o que um programa faz, mas se ele foi escrito por uma pessoa, pelo menos dá para assumir que houve alguma intenção ali
Com código gerado por IA, você pode nem saber por que aquilo foi parar ali
Tem gente demais publicando projetos vibe coded pela internet e, no começo, escondendo esse fato enquanto diz apenas “eu fiz” e leva todos os elogios
Aí depois, quando fica claro que a pessoa não escreveu nada e nem entende como funciona, ela tenta normalizar com “não tem problema usar IA”
Mas usar IA como ferramenta e simplesmente copiar e colar sem compreender nada, vendendo tudo como mérito próprio, são coisas completamente diferentes