I'm Going With MeshCore

I got into mesh networking through Meshtastic, wrote about it, got interested in MeshCore as an alternative, wrote about that too, and then watched the project go through a pretty public and unpleasant split right as I was getting started. I covered the drama in a previous post. This one is about what I decided to do after it.

The short answer: I am going with MeshCore. Specifically, the team at meshcore.io. And I want to say a bit about why, because it is not purely a technical decision.

The technical side is actually fine

Let me get this out of the way first. The firmware from the meshcore.io team is good. v1.15.0 shipped on April 19th and added six new hardware platforms, enabled the low-noise amplifier by default across supported devices, and included OTA update support for nRF companions. They have shipped over 85 firmware versions since January 2025, across more than 75 hardware variants.

The T-Deck Plus I am planning to buy is on the supported hardware list. The 868 MHz band is correct for the UK. The flasher is at flasher.meshcore.io and takes about ten minutes. None of that changed because of the drama.

What actually made me decide

I have been thinking about the AI firmware question more than I expected to.

The core team’s position is that all of their firmware is hand-crafted, by humans. They were not prescriptive about what other people do with AI in their own projects, but when one of their own contributors was secretly building large chunks of the ecosystem using Claude Code and not disclosing it, that felt like a meaningful breach. Not because AI assistance is categorically wrong, but because transparency about how critical infrastructure is built actually matters.

Mesh networking is not a widget. People use it for communication when normal infrastructure fails. The firmware running on these devices needs to be auditable and traceable to people who are accountable for it. When something goes wrong in a mesh, you want to know that the people who wrote the code understood what they wrote.

The trademark filing was the more clear-cut problem. Filing a trademark application on a project name without telling any of the people who built the project is just a bad thing to do, regardless of what you think about anything else.

But the AI thing is the one I keep coming back to. It is not really about the tools. It is about honesty. The core team found out that a significant portion of what was being promoted as MeshCore ecosystem tooling was majority vibe-coded and that detail had been kept quiet. That is the thing that broke the relationship, and it is hard to argue they were wrong to be bothered by it.

The practical stuff

The split means two things have changed for setup instructions going forward.

The flasher is now at flasher.meshcore.io. The old meshcore.co.uk flasher is not associated with the core development team.

The canonical home for everything is meshcore.io. GitHub is at github.com/meshcore-dev/MeshCore. The blog, release notes, and documentation are all there.

The app is the official MeshCore App, developed by Liam Cottle, available for Android and iOS. Not MeshOS. Not anything Andy Kirby is shipping under the MeshCore name.

If you have already flashed firmware from the old flasher, it is worth checking which version you are on and reflashing from flasher.meshcore.io to make sure you are on a build from the core team.

Where I land

I still think this is the right technology for what I want to do. Off-grid mesh communication, a standalone terminal that does not need a phone attached, something I can actually understand and maintain. The T-Deck Plus plus MeshCore still ticks all of those boxes.

The drama did not change that. What it did was make me more careful about whose resources I am pointing at, and more interested in the question of how the software I rely on gets built.

For now: meshcore.io, the core team, the human-authored firmware. That is where I am landing, and that is where I will be pointing future articles in this series.