Introduction
One of the most interesting—and challenging—problems in building the EmergencyHam.Net architecture is not technical at all.
It’s regulatory.
As we begin to explore bridging modern encrypted communication systems—such as mesh networks and mobile messaging—into amateur radio, we run into a fundamental rule:
Amateur radio transmissions must not obscure their meaning.
At first glance, this might seem like a limitation. But in reality, it forces a deeper and more important question:
How do we responsibly connect modern, private communication systems with open, regulated radio networks?
The Real Problem Isn’t Encryption—It’s Meaning
It would be easy to say:
“We’ll just decrypt the message and send it.”
But that’s not enough.
A decrypted message could still be:
- encoded
- obfuscated
- machine-generated
- or deliberately structured to hide its meaning
So the real requirement is stronger:
Only forward messages into the ham network when they are clearly intelligible as plain language.
That’s a very different standard.
Introducing a New Architectural Component
Through this discussion, we identified the need for a dedicated part of the system:
Content Transparency & Compliance
This is not just another filter—it is a decision point in the architecture.
It sits between message processing and ham transmission:
Ingress → EMP Normalize → Identity/Policy → Compliance Gate → Ham Egress
Its job is simple to describe, but critical to get right:
- ensure the message can be understood
- ensure it is attributable
- ensure it meets policy
- ensure it is safe to transmit
What Does “Plain Language” Actually Mean?
We quickly realized there is no single test for this.
Instead, we use a layered approach:
- can the message be decoded into readable text?
- is it mostly printable characters?
- does it resemble natural language?
- does it avoid long random or encoded sequences?
- can an operator read and understand it?
This produces a confidence score, not just a yes/no answer.
👉 This is important:
We are not trying to “prove” something is safe—we are building enough confidence to act responsibly.
Automation First, Humans When Needed
The system is designed to make most decisions automatically, but not blindly.
Each message falls into one of four categories:
- PASS — clearly plain language, safe to forward
- PASS WITH RECORD — forward, but retain full audit record
- REVIEW REQUIRED — hold for operator decision
- BLOCK — do not transmit
This allows the system to scale, while still respecting the role of the control operator.
Logging Becomes More Than Logging
This discussion led to an important realization:
The compliance system is not just a filter—it is an evidence system.
For any message that crosses into the ham network, the gateway will:
- log the full plaintext
- record origin, destination, and path
- store a compliance decision
- retain the record for 30 days
- protect it with encryption and tamper-evident hashing
This ensures that:
- decisions can be reviewed
- misuse can be investigated
- operators remain accountable
- the system remains trustworthy
Local First, Network When Available
Because EmergencyHam.Net is designed for off-grid use, we cannot depend on central systems.
So we adopted a simple principle:
Logs are local and authoritative. Central copies are optional.
Each gateway:
- keeps its own secure compliance log
- continues operating fully off-grid
- forwards logs to central nodes when connectivity exists
This gives us:
- resilience in emergencies
- visibility when networks are available
- no single point of failure
Why This Matters
This is one of the most important steps in the project so far.
It moves EmergencyHam.Net from:
“a system that connects networks”
to:
a system that connects networks responsibly
It also addresses a key concern anyone will have when reviewing the architecture:
- Can this be misused?
- Can it be trusted?
- Can it operate within existing regulations?
By designing for compliance from the beginning, we avoid having to retrofit it later.
Looking Ahead
This is just the first version.
Future work will include:
- refining plaintext confidence scoring
- improving operator review tools
- defining key management for logs
- correlating logs across multiple gateways
- integrating compliance decisions into routing
Final Thought
It’s easy to focus on radios, protocols, and networks.
But systems like this ultimately succeed or fail based on trust.
This work is about building that trust—into the architecture itself.
👉 If you’re interested in helping shape this work, review the documents or join EmergencyHam.Net as a founding member.
Leave a Reply