MeshCore development team splits over trademark dispute and AI-generated code

don’t forget that although it already works fine on lora, it’s a protocol that’s transport channel agnostic, and is gonna do great with other transports (halow, optical, wifi, whatever) when people finally start realizing that lora is never going to be able to keep up with bandwidth/speed requirements of anything much beyond simple text messaging.

although, i’ve already done real time voice calls over 1 hop of reticulum lora on and it works pretty ok.

edit - community wiki with getting started instructions is here:

https://reticulum.miraheze.org/wiki/Welcome

I spent an entire month trying to build something with Reticulum, but there just isn’t great tooling for dealing with the protocol. Makes for a pretty infuriating devex if you’re just trying to build your app.

Neat concept but so many footguns that (imo) it’s not really sustainable to try bootstrapping.

Specifically, I had tried to port the stack to Rust no-std to use on nrf52 LoRA devices to use/abuse the existing MeshCore network to deliver reticulum packets. Turned out to be a nightmare just trying to figure out if my packets were even correctly formed.

I've never seen a working Reticulum network in the wild.

Only very very small testbeds.

Which frequency do you get? Does it matter?

I wish nomadnet got rewritten in Go.

I get the feeling the culture in radio is just not the same as regular open source. The free unrestricted sharing of things is an unusual quirk in the world rather than the norm.

I don't know any of the players but I'd bet they're licensed amateur radio operators.

For now, I don't think it's fair to compare MeshCore with MeshTastic in terms of enforcement as that has not happened with MeshCore. This seems to be one guy getting a trademark in the UK without the approval of other members of the team. They're not going after anyone. Not yet, at least.

The protocol is CC and Mark has said go wild, it seems he doesn't want his work to contribute to an unstoppable AI killing machine networm

> What is it with mesh projects and having these super draconian trademark enforcers?

Simple. Follow the money. Meshcore has more than 100k of users, repeaters are cropping up like weeds across the world. And that means there is a serious incentive to "cash out".

Notably, the person "cashing out" here wasn't involved in Meshcore firmware or app development, but in marketing.

All meshtastic code is GPL, the name "meshtastic" is owned by the company that developed it. You can use any of the code, you can't use their name outside their rules. This is absolutely no different than, say, Firefox. The trademark policy is very permissable and you don't even need their permission to use the name on a commercial product.

I think it's totally sensible for the organization to want to have some level of control over what gets their label on it -- the Wi-Fi people wouldn't be very happy about someone slapping their logo all over a bunch of completely incompatible hardware.

Agreed. I use meshcore and have multiple repeaters setup. I don't care about people using ai assisted coding but I think it should be disclosed especially if its closed source.

Now the trademark take over seems crazy especially given Andy hasn't contributed to the github project, only personal for profit add ons.

I do also think that the meshcore core team have "tacked on" and tried to enforce a stronger narrative with their anti ai coding bias.

> Is the code bad? It sounds like they had no idea he was using AI. That seems to imply there was nothing wrong with the code as-is. Why not judge it on it's merits?

Anyone that has used AI at all knows this isn't how it works. AI is extremely good at producing plausible-but-wrong outputs. It's literally optimised for plausibility, which happens to coincide with correctness a lot of the time. When it doesn't you get code that seems good and is therefore very difficult to judge on its merits.

With human written code it's a lot easier to tell if it's good or not.

There are exceptions to this - usually if you have some kind of oracle like that security work that used AddressSanitizer to verify security bugs, or if you're cloning a project you can easily compare the behaviour to the original project. Most of the time you don't have that luxury though.

I feel the same way, and both mobile apps are pretty janky, with Meshtastic being extra obnoxious because the UI teams between Android and Apple apparently don't talk to each other- very hard to onboard/answer questions from someone new if you're on a different platform than them.

It was fun and cheap to set up, but I look forward to something with better messaging persistence so you can at least reliably not miss stuff.

I largely agree and want to add more,I also think the lack of standards also will effect it's usability in a real shtf scenario. why should I use meshstastic over meshcore for example. I also don't think lora will be in my mind in that kind of scenario.

I got to participate in a game that used Meshtastic and GPS where you walk around a large camp and "capture" different regions. It worked great for that and was a lot of fun.

If there ever where a more serious situation where my life depended on one of these meshes, I would be feeling pretty uneasy. They are absolutely not reliable enough to even consider such a thing. I suppose they might be better than nothing.

To say nothing of what is required to set up the devices. I wanted to put a full dev system on a raspberry pi 3 just so it would all be in one place and I could work on it when in a location with no internet - it ran out of memory trying to compile the massive web app that is the default client interface.

SHTF?

I develop an open-source self-hosted client (very mobile friendly) for base-station radios that you want to use from anywhere, and also support MQTT/community observers/bots/webhooks/etc. It spawned out of my need for a daily-driver client that wasn't chained to the radio, and turned into a super fully featured companion client for power users.

The radio API and firmware is open; I have no ire for people who choose to make software closed source so that it can be monetized when there are SO many other options that in many cases supersede the functionality of the closed source option.

https://github.com/jkingsman/Remote-Terminal-for-MeshCore

https://github.com/zjs81/meshcore-open

The closed client isn't needed anymore.

Wow, very surprised to learn that it is closed source, and that's probably not changing.

My local mesh was testing out meshcore last week, this definitely kills my interest too

I'm ignoring the attempted trademark trickery because TLDR; blah AI is evil blah blah other stuff.

You're right, I don't know who would down vote or disagree with this. It's not easy to figure out what a program is doing, but if someone wrote it you at least know there was some sort of intention there. With AI you have no idea why it's there.

All over the internet people are putting up vibe coded projects and no one says that's what it is up front. They all just say "I made this" and they are more than happy to take in the adulation of people impressed that they made something with an animated pattern.

Then when they finally admit that they wrote nothing and don't know how any of it works people start to say "nothing wrong with using ai", as if using it is the same as copying it verbatim, not understanding anything and taking complete credit as if you wrote it while lying about how it was used.

Wow, #4 is frustrating. (Disclosure: am a ham, but not one of the uptight ones. I'm not personally offended when someone breaks the rules, and I'm not gonna run off and call the FCC or something. But I am concerned when they don't seem to know or care why.)

First, I don't know if their interpretation of the rules is correct. For the sake of argument, I'll assume it is. More importantly, most other people in that thread seem to be going along with the idea that it is correct. This is how it reads to me:

Submitter: We're violating the rules and should make this change.

Replier 1: That change would be inconvenient in Seattle so we're not doing it.

Replier 2: It wouldn't work well in Boston, either, so it's a no-go.

Part of me wants to shake them. This isn't 'Nam. There are rules. Whatever you think about the FCC regulations, they're not voluntary, and they certainly don't have an opt-out for "it wouldn't work as well that way". To a first approximation, everyone else using the public airwaves is more or less following the law. If following the law makes your project not work as well, that's your problem. It's on you to fix your project so that it's legal to use.

I'm not one of those old hams who gets hyper cranky about this stuff, but I do understand how they come to be that way. The only reason we can use the spectrum at all is that people are mostly using it legally so that their work isn't interfering with everyone else trying to use the same public resource.

>Would you trust AI generated mesh firmware?

This is also a loaded question. The only specifics they've offered are that he simply used Claude Code. Um... OK? Do the tests pass? Did his changes add any security flaws? Regressions that were untested?

What's an example of a GPS coordinate "outside earth's bounds"?

what's even the need to transmit/receive GPS as part of the protocol?

> It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.

Agreed, but at least it's somewhat sensibly structured. AI? Good lord you'll end up with a slopaghetti mess.

> They don't even have automated tests and ignore attempts to add them.[0, 1, 2, 3]

Two people, 540 issues and 270 PRs open at the moment. Not wanting to be that guy... but do the math. The reviewer team is small as hell and after this drama (which probably kept both of them busy with BS) they'll likely be even less willing to trust others.

If you want to stand a better chance at getting your code into other people's hands, go and contact the person behind the Evo fork. IIRC he's part of Hansemesh, Germany's biggest regional MC.

I have heard indirectly multiple times now that the only two ways to get a PR of interest merged is to either gather enough people to Like the issue on Github or to join the Discord and ask.

[1] https://github.com/mattzzw/MeshCore-Evo

The 802.11ah offerings right now are a mess though. Mostly proprietary and just generally very buggy. I don't know of a single chip that can actually be used with up-to-date Linux. Do you? Be it Morse Micro, Newracom, Taixin or any other, they all suck in some aspect.

Hostapd people also do not seem interested in bringing in any 802.11ah support. So it's crap in that aspect as well. Drivers all fake 802.11n or the chipset offers some garbage AT-command interface and does all of the networking.

On the other hand MeshCore and Meshtastic have similarly terrible codebases as far as I've seen. At least they're somewhat usable though.

Honestly no clue why these software stacks are all this dangerously written, unstable and haven't improved in years.

LoRA is extensively used in Ukraine right now as a UAV control rf link to bridge serial uart from ground control system to uav. In its most narrow channel configurations at lower bps and using things like 1.2GHz tuned yage antennas it can have some very robust jamming resistance.

Eh, I've played with 802.11ah and it's very long range for the power, but way too stateful for the use case that these mesh protocols serve. If you go out of range it's several seconds to re-establish a connection. I've worked with proper mesh radios (Silvus, etc) and they work very differently.