When we first talked about EmergencyHam.Net, it was very much an idea.
A good one, we thought—but still just an idea.
Could you take all these different ways people communicate—radios, mesh networks, phones, and the internet—and make them work together in a simple, reliable way? Especially when systems aren’t behaving the way they normally do?
That was the question.
Over the past few weeks, things have started to shift from “what if” to “this might actually work.”
A Small Build That Changed Everything
One of the first things we built was simple on the surface:
A bridge between SMS and a mesh radio network.
No big framework. No complex infrastructure. Just a way to take a text message from a phone, push it into a radio-based network, and return the reply.
But once it was working, something clicked.
You could send a message like:
“Need supplies at checkpoint”
…and it would travel through a completely different kind of network—one that doesn’t depend on cellular or internet infrastructure.
When the reply came back, it appeared on the phone like any other text.
No special apps. No explanation needed.
That’s when it stopped being theoretical.
Stepping Back to See the Bigger Picture
After that, we paused and asked a bigger question:
What are we actually building?
Instead of continuing piece by piece, we documented the system as a whole—creating a structured, versioned design.
At a high level, it comes down to three ideas:
- Messages are addressed to people or locations, not devices
- The system determines how to deliver them
- Different networks should work together naturally
A Simple Way to Think About It
Every message starts somewhere—a person, a sensor, or a system.
It’s addressed to a destination:
“Send this to CLINIC01”
Each step in the network doesn’t need full awareness of the path.
It simply asks:
- “Is this for me?”
- If not: “Where should this go next?”
The message continues moving until it reaches its destination.
Where It Gets Interesting
This model changes how you think about communication.
You don’t need to decide in advance whether a message will travel over:
- radio
- mesh
- internet
- SMS
The system handles that dynamically.
And more importantly:
The user doesn’t need to care.
They just send the message.
What We’re Building Next
We now have:
- A working prototype (SMS ↔ mesh bridge)
- A defined architecture
The next step is bringing those together into a more structured system.
A More Structured Mesh Layer
We’re exploring how this could run on platforms like MeshCore, with additional structure layered on top.
The goal is to move from:
“Messages happen to get through”
to:
“Messages are handled in a consistent, predictable way”
Connecting to APRS
APRS has proven its value over decades.
We’re looking at how to integrate with it in a way that:
- Respects how it’s used today
- Enables more structured data alongside traditional messaging
Looking at Winlink
For longer messages and store-and-forward communication, Winlink provides another important path.
It operates differently—but fits naturally into the same overall architecture.
Where This Is Heading
This didn’t start as something this broad.
But piece by piece, it’s becoming clear:
This isn’t about one network.
It’s about making all of them easier to use together.
Still Early—But Real
There’s still a lot to figure out.
But we now have:
- A working prototype
- A defined architecture
- A clear path forward
And that’s real progress.
From Concept to Controlled Architecture
As the pieces started to come together, it became clear that this needed more than notes or diagrams—it needed a defined structure.
We’ve now captured the current system design in a formal, versioned document:
EmergencyHam Full-Stack Summary (v0.2)
This document represents the current controlled architecture of the system.
It defines:
- What is already stable and agreed
- How messages are structured and routed
- How different networks interoperate
- Which areas still need refinement
At its core, it confirms that EmergencyHam is built around:
- Identity-based communication (people and locations, not devices)
- A consistent message format across all networks
- A hop-by-hop routing model
- A layered architecture separating applications, messaging, and transport
Just as importantly, it also identifies the open areas—routing intelligence, delivery behavior, trust models, and operational policy—that will shape the next phase of development.
Leave a Reply