I've found Meshtastic is simply not ready to be set up in an environment without internet, as I discovered when I brought some of the boards I bought with me on vacation to a rural area with more space to test them, but very limited internet.
The entirety of the meshtastic project is web first.
- To flash your boards, the suggested method is their "Web Flasher", and if you download the firmware source, it depends on PlatformIO (and the internet) to download and install the toolchains and flasher programs you need.
- The clients for meshtastic are available on the app stores, or as a web app at https://client.meshtastic.org/ None of these are offline. I did later learn the boards themselves host the web app, but they still have to be connected to an Wifi AP, you don't get it just by plugging the board into your computer.
- The docs are hosted at https://meshtastic.org/docs. "Download Docs" or "How to self host this project" are not topics described there or anywhere else. A technical person could figure this out, but this is seemingly not a primary concern.
I suppose this is the very point of this post, to get people to have it all set up beforehand, but not even having the docs as a PDF I can read offline? I learned about Meshcore too in this thread, but if I go to their site and the "getting started" guide is a Youtube video, then you're not ready for an emergency!
I only ever flash via CLI or via "drag & drop" method. The web flasher is great for first-timers but there are 100%-offline methods for all the devices.
The android client .apk can be downloaded directly from github at https://github.com/meshtastic/Meshtastic-Android/releases
I do agree though, I feel there should be more effort to support "long term lack of internet" use case.
For this use case - internet resiliency - I suspect the availability of un-flashed LoRa boards will be approximately zero in situations where it's needed. I agree that building an offline capable tool chain would be a good idea (perhaps all you'd need would be RasPi sd cards already flashed with everything needed to flash and configure common LoRa boards, and an archive of android apks?) But if I were allocating internet resiliency club resources, that'd be fairly low down my list.
I think that depends on the scope of the risk someone is trying to mitigate.
As an example, Hundred Rabbits is living in a situation with extremely iffy internet. They live on a sailbot and work in computing out there. They have had to build their own tools that were not dependent on a reliable internet, or even reliable power sources.
- https://100r.co/site/tools_ecosystem.html
- https://100r.co/site/off_the_grid.html#internet
Collapse OS and Dusk OS are projects that are building tools to mitigate against the risk of society collapse. These are scenarios where, not only is there no internet, there is no longer any capability to fabricate any more silicon chips, and people start scavenging existing systems.
- https://collapseos.org/
- https://collapseos.org/civ.html
- https://duskos.org/
depends. I have a pretty good stash of compatible devices going back a few years (as I've been tinkering with meshtastic since 2022), and some are on very old firmware versions. If "SHTF" unexpectedly and I needed to deploy them to as many community members as possible, a good percentage of them would be useless because they are not compatible with the newer versions of the firmware. (on the upside, I do stash the firmware zips on my NAS, along with tons of other OSes, drivers, firmwares, etc.)
- Compiled firmware is available on GitHub, packed together with a script for flashing it.
- You can use Meshtastic CLI.
- Docs are in git repository in .mdx format: https://github.com/meshtastic/meshtastic
All "sins" you mentioned are results of trying to be more convenient for users used to web browsers. Current state of web is pretty far from being decentralized, including web3.
What happens when you can't access Github?
I think a lot of those problems get solved with scale and diversity of users/contributors.
Look at Linux. In the last decade there's been a huge boon and tbh, the biggest part of that is usability. UI/UX got a lot nicer and cleaner. I mean another part is Microsoft and Apple getting more hostile and people looking for alternatives, but usability is what provided those people space and a larger more diverse community is what made it more approachable.
What I'm saying is, keep up the criticism but let's also make sure to interpret it as feedback rather than pure complaint. So we can turn these things into what they can be. After all, this is the place where we make great products, right?
And never underestimate the criticality of documentation. It seems burdensome and annoying since it is always changing, but you can't get people to join your cause if they don't know how to. In your company or your OSS project. It's a very profitable investment
I think your client specific concerns may not be valid.
The web app seems to work fine offline. Save the page with your browser.
Android app is available pre-built on github.
iOS app can't be distributed to end users offline because of Apple. Blame them or buy a better phone.
> you don't get it just by plugging the board into your computer
Which btw is a rather trivial thing to implement. I've seen devices host a control webserver with Ethernet-over-USB just for convenience.
Hearing this is exciting to me, because it is a very concrete and actionable target for a true “local-first” ecosystem and infrastructure.
I was very disappointed to find that the “local-first” manifesto was not the “local-first” as I understood it. In my mind, I should be able to connect an app on my phone to another phone via bluetooth, and sync without going through a central server. However, it makes very little economic sense, if someone is building a SAAS product that locks customers into dependencies on a central server where services can be metered and billed. To my mind, those are “offline-first”.
I have thought about what it would take to build a local-first software forge and package distribution, and yet, I couldn’t see a good reason to expend that effort. We have a lot of the pieces … with this example — if we want to be able to expand a meshtastic network _after_ a disaster, then the whole tooling, development, etc. needs to be local-first and resilient.