MeshCore vs Meshtastic — the gist

Neither is “better” in the abstract — they make different tradeoffs. MeshCore tends to be more compact on the air; Meshtastic tends to be more featureful per node.

The split — context

In late April 2026 the MeshCore community fractured. The shorthand “the split” refers to a public falling-out between the core team (Scott et al.) and Andy Kirby, a previously-active contributor.

Read the team’s account: blog.meshcore.io/2026/04/23/the-split

The disagreement is worth understanding for two reasons:

1. It clarifies who owns what today — the official meshcore.io site, the GitHub org, the trademark, and the Discord are all currently contested or freshly-relaunched.
2. The substance of the dispute — how transparent should AI-generated code be in firmware? — is a question every project using Claude / Copilot / etc. will face soon.

The split — what happened

• The MeshCore project was driven by a small team: Scott (founder, firmware lead), Liam Cottle (apps), Recrof (maps), FDLamotte (Python tooling), Oltaco (bootloader). Andy Kirby was a member.
• Andy began using Claude Code extensively to develop components across the MeshCore stack — devices, mobile apps, a web flasher, config tools — but didn’t disclose this to the team.
• On 2026-03-29 Andy applied for the MeshCore trademark without informing the team, then stopped responding when the team tried to discuss it.
• Andy retained control of the original meshcore.co.uk domain and Discord server, and (per the team) copied the team’s visual design.
• The team’s account describes it as having “an insider team up with a robot and a lawyer,” and explicitly commits to “human-written software” going forward.
• They relaunched at meshcore.io, with blog.meshcore.io and a new Discord. The trademark situation remains unresolved.

The team’s stated position is human-written as a core value. The split therefore reads as much about disclosure as it does about authorship — the team’s objection is to a long period of undisclosed AI involvement, not (necessarily) AI assistance itself.

The split — multiple readings

Reasonable people read this story differently. A few framings to hold in tension:

• Trust and disclosure first. The most-cited objection is that AI use was concealed. If Andy had been open about it from the start, the trust dynamics — and the trademark question — might have played out very differently.
• Authorship and accountability. “Human-written” is a defensible posture for firmware that runs on people’s devices: it implies a person understands every line and can answer for it. AI-assisted code raises real questions about who debugs the obscure failure mode at 3 AM.
• The pragmatic counter. Modern infrastructure is increasingly co-authored with LLMs. Drawing a hard line risks foreclosing a productivity gain that’s already mainstream — and many tools the community uses (compilers, linters, language servers) are also “robots” in a sense.
• Trademark vs. open source. A trademark grab on an established open-source project, by any party, is a separate concern from how the code was written. Both can be true.

Where you land probably depends on which value you weight first: transparency, authorship, or pragmatism.

OpenCore — what’s open, what isn’t

• Firmware — open at github.com/meshcore-dev/MeshCore. MIT-licensed. Every opcode in the companion protocol is implementable from this source.
• Companion protocol spec — open at docs/companion_protocol.md in the same repo. (Incomplete; the source is the source of truth.)
• Official iOS / Android apps — closed source. Distributed via the app stores by the core team.
• Official web flasher — open-source.
• Map server / room servers — open-source.

This is a textbook opencore split: the protocol and reference hardware are open, the polished consumer surface is not. Reasonable from a sustainability standpoint, frustrating if you want to (a) inspect what the app does on your device, (b) extend it, or (c) build something the official app intentionally doesn’t.