Introducing EnvyOS
When I bought my first mesh radio, I honestly thought I would turn it on and start talking immediately. That is not what happened. I ran into settings, radio frequencies, and terminology I had never needed before. The app did not work very well either. The whole experience was sobering. If I was struggling, I could not imagine a busy parent having any luck at all.
That parent is the avatar I keep in my head. I picture a mom who drops something the size of an AirTag into her purse, opens an app on her phone, and gets help when she needs it. Flat tire, kids in the car, middle of the desert, no cellular reception. I want that to work without her needing a crash course in LoRa presets first.
I also think about the backpacking photographer who knows his trade and his camera gear cold, but not mesh networking. I want him to reach the farthest corners of Nevada, stay in touch with his group, or call for help without needing the equivalent of a ham operator's license to do it.
EnvyOS is what I am building toward: a comprehensive distribution with firmware, a bootloader, and client apps that fit together from the first launch. I am sharing it now because the pieces are starting to line up, not because the whole vision is finished.
Why I keep at it
I think we are on the cusp of something huge with mesh networking, and I want to experience all of it and contribute however I can. Plenty of people in this community have great ideas and a much deeper grasp of radio physics than I do. I try to keep a curious mind and learn from them.
What I have noticed along the way is that the hobby aesthetic, lots of buttons, dials, and settings to fiddle with, works for some of us. It leaves a lot of other people out. Radical simplification feels underserved to me. That is the gap EnvyOS is aimed at.
Longer term, I would like a physical LoRa radio to be optional. Install the app, start chatting, and let the infrastructure carry messages onto the mesh when and where it makes sense. We are not there yet. Client apps are a big part of how I think we get there.
Standing on community work
EnvyOS is not a from-scratch stack. It pulls together open source projects that already do real work in the field: MeshCore, motatool, OTAFIX, and contributions from people like vk496. My part is mostly integration, field testing, and packaging the pieces so they feel like one thing when someone new shows up.
Whenever we build something that belongs upstream, we contribute it back. Routing improvements, OTA primitives, tooling. The community did the hard foundational work. EnvyOS is my attempt to turn that into something a person can actually pick up and use.
I also want to stay backward compatible with MeshCore. Real networks are already on the air in Nevada. I would rather add to what works today than ask anyone to start over.
Firmware updates over the mesh
The piece that unlocked a lot of this for me came from vk496 in France. He figured out how to send firmware updates over the mesh. I had been chewing on that problem for a long time myself, trying design after design. His approach solved fleet management in a way I had not reached, and it opened the door for the other improvements I wanted to stack on top.
His OTA stack uses idle airtime to move updates and other data across the mesh. That matters to me because I can try a routing change, push it to repeaters in the field, see what actually happens on real links, and try again. Lab time is useful. So is a jeep on a mountain pass.
We have wired that work into EnvyOS through firmware, an OTAFIX bootloader, and motatool for packaging and serving .mota artifacts. If you caught the mention from Desert Peak / Toulon, this is the same thread, now with a distro repo behind it.
If I ever make it to France, I am buying that guy a snail. It is the least I can do for some of the most outstanding community work I have seen in the last year.
Message reliability at distance
Nevada does not do small geography. We already have backbone nodes hundreds of miles apart. Lately I have been feeling the pain of getting administrative messages through reliably as those distances grow.
Other people are working on routing improvements. So am I. What EnvyOS adds is the OTA loop. Ship a tweak, push it across the fleet over LoRa, watch the real-world result, iterate.
One example I have been working on is next-hop retry on direct-path repeaters. If a forward fails, the mesh gets another chance instead of dropping the traffic quietly. Small change. It helps when the next hop is forty miles away.
Remote seeders on solar repeaters
The next thing I am exploring with vk496 is remote seeders. The idea is to use RAK's modular system on solar repeaters, give them 32 GB or more on a microSD card, and treat that storage like mesh-scale torrent seeders for firmware and other bulk data.
Picture a backbone repeater on a ridgeline with no USB cable and no technician visit scheduled for months. It advertises the .mota files it has cached. Nodes downstream fetch during idle airtime. Updates spread without anyone climbing a tower with a laptop.
That is the kind of fleet management Nevada-scale distances actually need.
Where things stand today
EnvyOS is early. Version 0.1.0 covers the firmware and OTA toolchain: MeshCore-based envycore, an OTAFIX bootloader, motatool, build scripts, and bench workflows for WisMesh Tag and RAK4631 targets. Client apps are still ahead of us on the roadmap, part of the same distribution story.
The EnvyOS repo is where the integration work lives. I am closing the gap between what works on my bench and what I wish had worked the day I unboxed my first radio.
What I am trying to hold myself to
I also want to take a page from the heritage of Linux distros. Debian, Ubuntu, Fedora, and the rest do not pretend they wrote every tool in the box. They assemble versions that are known to work together, add their own customizations, tooling, and apps, and ship one coherent offering. The value is not in claiming authorship of each package. It is in the interoperability and internal consistency of the whole thing. That is what I am aiming for with EnvyOS.
As it grows, these are the commitments I keep coming back to:
- Proper attribution. Say clearly who built what.
- Simplicity for the end user. Fewer settings, clearer defaults, one path in.
- Contribute upstream. Give features back to the projects they came from.
- Stay open source. The mesh only scales if people can trust what they are running.
There is a long road ahead: app-first onboarding, infrastructure-side LoRa bridging, seeder repeaters, routing that keeps up with Nevada-scale distances. If you already run MeshCore repeaters in our coverage area, nothing changes overnight. I will document each release plainly as it becomes something I would actually recommend to that mom with the flat tire or the photographer on the trail.