I feel it's about time I made my stance on the #Meshtastic versus #Meshcore debate quite explicitly clear.
First of all, as of now, I use Meshtastic because there are absolutely no Meshcore nodes anywhere near me. I flashed my radio to Meshcore and checked over a 24 hour period.
What Meshtastic does right:
Fully open source everything: When I first heard of Meshcore it was being promoted by a YT influencer named Andy who was pushing an app that was "the same between iOS and Android with no janky different version" while failing to discuss the fact that it was CLOSED SOURCE SHITWARE! The meshcore flasher page also has firmware for certain devices that is proprietary and does not tell you which one is open source and which one is closed source shitware. This has tainted my view on Meshcore severely until I learned of the open source alternatives Meshcore-open (
https://github.com/zjs81/meshcore-open) and Meshngr (
https://github.com/satsdisco/meshngr), but for an entire year, it was completely closed source apps only.
Presets: Meshtastic has easy to use presets such as LongFast, MediumFast, and ShortFast to get you meshing quickly and documentation on data rates versus range for channel congestion mitigation. Meshcore is like "choose your frequency, spread factor, bandwidth, and coding rate with no guidance. The user must look up local information from online maps and if channel utilization gets too high, there's no guidance on what to do to get higher data rates. Maybe the proprietary apps have some presets, but again, since they are closed source shitware, I'm not going to touch them.
What Meshcore gets right:
Simplicity: Meshngr's goal is to reduce or eliminate the mesh "jargon" and meshcore-open has much fewer and better managed settings than meshtastic. For absolute simplicity, Meshcore is a win hands down, no contest, do not pass "Go", do not collect 0.5 #Monero.
Region filters: These keep messages that are supposed to be in a specific area, in that specific area. This is fantastic for keeping congestion on the mesh down, because if a repeater doesn't have the region scope in it, it will not relay that message outside of that region. As an example, if Tampa, Florida and Jacksonville, Florida have a mesh link between each other that is functional at all times, they can have region scopes so that messages meant to be seen by Jacksonville people can be seen by only Jacksonville people and messages for Tampa people can only be seen by Tampa people. Of course, users are free to send a message to the public channel, which can be seen as far as the mesh will go, and by everybody, but they don't have to if they're talking about some local attraction or topic. (I hope meshtastic adopts this)
The so-so
Meshtastic CLIEN versus Meshcore Companion: (relaying): Meshtastic choose to use a default role of CLIENT which will relay a message if it has not heard that message be relayed by a ROUTER or another local CLIENT with a strong signal. Meshcore companions only relay messages on a specific frequency and only if they are put in a special "outdoors" mode. This keeps meshcore companions from repeating messages and clogging the public mesh since it only allows companions to repeat after being put in that mode and forces it onto a different frequency. This is a compromise because otherwise you must have a repeater for meshcore companions to talk with each other if they cannot see each other which made Meshcore not a great option for things like hiking or deer hunting.
By making every node a CLIENT by default Meshtastic naturally has higher congestion levels due to more repeating nodes and can suffer from "hop gobbling" where your message does not get as far as it could because of repeating nodes in not great areas. Your node in your backpack makes for a fucking terrible repeating node as it's only a few feet above the ground and therefore does not get your message very far at all. This also means that by default, meshtastic uses more battery power since it is relaying messages for others even when it is kind of useless to do so.
The compromise would be if meshtastic were to make a 50-50 split, where, upon very first setup, 50% of the nodes would become CLIENT nodes while the other 50% became CLIENT_MUTE nodes that do not repeat messages. The user could obviously change the role if need be.
