Author: ukwebguy

  • Exploring APRS as Part of the EmergencyHam Network

    Exploring APRS as Part of the EmergencyHam Network

    As we prepare EmergencyHam Network (EHN) for its first alpha trials, we’re also looking ahead at additional communications systems that could become part of the network.

    One of the most interesting is APRS — the Automatic Packet Reporting System.

    APRS is already widely used by amateur radio operators for position reporting, short messages and other information. For EHN, however, APRS could potentially serve two quite different purposes: giving amateur operators access to EHN and providing radio links between EHN basestations.

    APRS as an EHN access point

    An EHN basestation equipped with an APRS gateway could have its own amateur callsign and SSID, for example:

    N2DH-10

    An amateur operator wouldn’t necessarily need to be a previously registered EHN member to contact it.

    A message might be as simple as:

    &NEWARK Need information on shelter status

    The & identifies an EHN group. The APRS gateway receives the message, records the sending callsign and passes the message into EHN.

    Because the station is operating through amateur radio, EHN could automatically create a limited provisional user record associated with that callsign. Registration or verification could take place later if the operator wanted full EHN membership.

    An unregistered operator could initially be restricted to published groups, while someone who already knows another member’s EHN ID could potentially send a direct message using the normal @user-id format.

    This gives amateur operators a simple way into EHN without requiring special EHN radio equipment.

    VHF APRS — local and regional communications

    We see VHF APRS primarily as an access and regional communications system.

    A local EHN basestation could receive messages from individual amateur operators and connect them with EHN users on completely different networks.

    For example:

    VHF APRS → EHN → MeshCore

    or:

    VHF APRS → EHN → SMS/RCS

    VHF APRS could also connect nearby EHN basestations, particularly where an existing APRS network provides coverage between communities.

    That means APRS isn’t simply another endpoint like a phone number or mesh node. It can also become a path through which EHN stations exchange traffic.

    HF APRS — a different role

    HF APRS introduces another possibility.

    Rather than concentrating on local user access, its most interesting EHN role may be as a long-distance, infrastructure-independent link between EHN basestations.

    Imagine two EHN stations separated by hundreds of miles. Under normal conditions they may communicate over the Internet. If that connection disappears, an HF APRS path could provide an alternative for important EHN traffic.

    Conceptually:

    EHN Basestation
          │
      APRS Gateway
          │
        HF RF
          │
      APRS Gateway
          │
    Remote EHN Basestation

    The originating station doesn’t need to know how the final recipient can be reached.

    It only needs to get the message to another EHN basestation. The remote station can then use its own directory and available gateways to complete delivery by MeshCore, Meshtastic, SMS/RCS or another available network.

    Making better use of limited bandwidth

    HF radio is a scarce communications resource, so EHN shouldn’t try to move everything across it.

    This is where EHN’s store-and-forward architecture becomes particularly useful.

    If normal Internet connectivity is available, EHN can exchange messages, directory information and operational data freely.

    If only VHF APRS remains, the system could reduce that traffic to information appropriate for the available capacity.

    And if an HF APRS link becomes the only path between two areas, EHN could become more selective still — carrying priority messages, essential routing information, acknowledgements and important operational updates while less important traffic remains queued.

    The user doesn’t have to choose the transport. EHN’s routing system can make that decision based on what paths are available and the priority of the message.

    Access or trunk — VHF or HF

    We don’t intend to define VHF and HF too rigidly.

    A VHF APRS connection could carry basestation-to-basestation traffic, and an individual operator could potentially reach EHN over HF.

    Instead, we’re looking at APRS in terms of two independent roles:

    Access Mode connects individual amateur stations with EHN.

    Trunk Mode connects one EHN basestation with another.

    Either could potentially operate over VHF or HF, with VHF naturally favoring local and regional access and HF becoming particularly valuable for longer-distance resilient links.

    Another piece of the EHN puzzle

    The goal of EHN isn’t to replace APRS, MeshCore, Meshtastic, cellular messaging or any of the other communications systems people already use.

    It is to connect them.

    APRS is particularly interesting because it could give EHN both a readily accessible amateur-radio interface and an infrastructure-independent way for EHN basestations to communicate with one another.

    It’s still an area we’re exploring rather than part of the initial September alpha trials, but it demonstrates where the EHN architecture can take us.

  • EmergencyHam Network Is Getting Ready for Alpha Trials

    EmergencyHam Network Is Getting Ready for Alpha Trials

    Over the past several months, the EmergencyHam Network has been moving steadily from an idea and an architecture into a working system.

    We are now approaching an important milestone. Starting in September, we plan to begin limited alpha trials of EHN with some of our members.

    There is still plenty of development ahead, and an alpha trial is exactly that — a chance to put the system into people’s hands, find out what works well, discover what doesn’t, and improve it. But we now have enough of the core system and gateways working that it is time to start testing the EHN concept outside the development environment.

    One Identity, Many Ways to Communicate

    One of the fundamental ideas behind EHN is that communications today exist in separate islands.

    A person might be using MeshCore or Meshtastic when away from cellular coverage. Someone else may only have an ordinary mobile phone. Amateur radio operators have networks such as APRS and HF digital modes, while Internet connectivity opens up still more possibilities, including email and other messaging services.

    Each of these systems can be useful, but normally they know very little about each other.

    EHN is being built to provide the layer that connects them.

    Instead of identifying someone by a particular phone number, radio node or network address, an EHN member has a unique EHN user identity. The EHN directory can associate that identity with the different ways that person can currently be reached.

    That means the sender shouldn’t need to ask:

    Is Steve on MeshCore, Meshtastic or SMS today?

    They simply send the message to Steve’s EHN identity. EHN determines which permitted endpoint and communications path can deliver it.

    This is what we mean when we describe EHN as transport independent.

    The Base-Station is Becoming Real

    A major part of our development work has been the EHN basestation.

    The basestation provides the intelligence behind an EHN installation. It handles identity resolution, routing policy, message storage, delivery state and the queues needed when a destination cannot immediately be reached.

    Around that core are gateways to individual communications systems.

    We now have working integration work for MeshCore, Meshtastic and SMS/RCS, giving us the pieces needed for some interesting first trials.

    The gateways deliberately don’t become independent routing systems. They deal with the mechanics of their particular network while the EHN basestation decides where a message is supposed to go.

    That distinction will make it much easier to add other communications technologies later.

    What might an EHN message look like in practice?

    Imagine someone hiking or camping outside cellular coverage but carrying a MeshCore device.

    They want to contact a family member who has nothing more exotic than an ordinary mobile phone.

    The hiker sends the message to the family member’s EHN user ID. The local EHN basestation receives it through MeshCore, looks up the recipient, discovers an SMS/RCS endpoint and sends the message through the phone gateway.

    A reply can make the journey in the opposite direction.

    MeshCore ↔ EHN ↔ SMS/RCS

    Neither person needs to understand the other’s communications system, and nobody has to manually relay the message.

    That’s a relatively simple example, but it demonstrates an important part of what we are trying to accomplish.

    What if the other network isn’t available?

    Real emergency and off-grid communications aren’t continuously connected.

    EHN has therefore been designed around store-and-forward operation rather than treating it as an exceptional condition.

    Receiving a message and delivering a message are separate events.

    If EHN accepts a valid message but the destination cannot currently be reached, it can store the message and queue it. When a suitable communications path becomes available again, delivery can be retried.

    That also means a local EHN station isn’t intended to stop functioning simply because its Internet connection disappears. It retains local identity, endpoint and operational information so that known users can continue communicating using the resources that remain available.

    Resilience to broken paths is part of the architecture, not something we intend to bolt on later.

    Groups can cross networks too

    The same principle becomes particularly interesting with groups.

    An EHN group might include people using MeshCore, others using Meshtastic, members who are reachable through SMS/RCS, and eventually participants on other supported networks.

    They can still participate in one EHN group conversation.

    EHN resolves delivery separately for each participant. A message might therefore leave the same basestation through several different gateways.

    Someone temporarily unreachable doesn’t necessarily lose the message either; their copy can remain queued until an appropriate path returns.

    EHN isn’t limited to chat

    Another area we want to explore is machine and sensor traffic.

    EHN’s addressing model includes the concept of a sink — a destination intended to receive information rather than represent another person.

    For example, students participating in a distributed environmental monitoring project could have small mesh-connected sensors at their homes.

    Their devices could submit readings to an EHN sink. EHN could validate and store those reports and then forward them to a school system, mailbox, web service or other configured destination.

    If that destination were temporarily unavailable, the reports could wait in the EHN delivery queue.

    It’s a useful example of how the same infrastructure developed for resilient human communications can support other kinds of distributed information.

    Amateur Radio Comes Next

    For our initial development and alpha testing, MeshCore, Meshtastic and cellular messaging give us an excellent environment in which to prove the core concepts.

    But amateur radio remains an important part of where EHN is heading.

    We are working toward APRS integration, and HF digital communications are also on the roadmap.

    Amateur-radio gateways introduce additional technical and regulatory considerations, so EHN treats them as controlled boundaries. Traffic crossing an amateur RF path must comply with the rules applying to that service rather than simply tunneling arbitrary Internet traffic across amateur radio.

    The objective remains interoperability while respecting the requirements of each communications network.

    September: time to start trying it

    This brings us to the next stage.

    During September we hope to begin putting early EHN software into the hands of a limited number of members.

    The first alpha trials won’t attempt to demonstrate everything in the long-term EHN vision. We want to start with the fundamentals:

    • Can users establish an EHN identity and use it naturally?
    • Can messages reliably cross between MeshCore, Meshtastic and SMS/RCS?
    • Does store-and-forward behave correctly when we deliberately remove communications paths?
    • Can a basestation continue useful local operation when disconnected?
    • What happens when real users do things we never anticipated during development?

    That last question may be the most important one.

    Alpha testing isn’t intended to prove that EHN is finished. It’s where we start finding out what EHN needs to become.

    Want to be part of it?

    EHN is still a small volunteer project, and September is also when we hope to start expanding the group of people actively involved.

    That doesn’t just mean software developers.

    We need people interested in testing, radio and mesh networking, Raspberry Pi and hardware, server administration, documentation, emergency communications, training, publicity and outreach.

    And we need ordinary users. A communications system tested only by the people who designed it isn’t much of a test.

    If you’ve already joined EHN, thank you for your patience while we’ve been building the foundations. We’ll be providing more information about the alpha trials as September progresses.

    If you’d like to take a more active role, this is an excellent time to contact us and tell us what interests you and what experience you might be able to bring to the project.

    After months spent designing, coding, integrating and testing the pieces, we’re looking forward to the next part: putting EHN in front of real users and seeing what happens.

  • Introducing the EHN Directory Security Architecture

    Introducing the EHN Directory Security Architecture

    Building Trust, Privacy, and Resilience into Emergency Communications

    EmergencyHam.net has always been about more than just connecting radios — it’s about building a modern, resilient communications framework that bridges amateur radio and today’s digital world.

    As the platform evolves, one of the most important new components is the EHN Directory — a system designed to enable identity-based communication across multiple networks, including:

    • Amateur radio (RF)
    • Internet-connected services
    • Local WiFi and edge systems
    • Message relay platforms like Winlink, APRS, and SMS gateways

    But introducing identity into a distributed communications system raises an important question:

    👉 How do you protect personal data while still operating legally over amateur radio?


    The Challenge: Privacy vs. RF Transparency

    Amateur radio operates under rules that prioritize openness. Messages transmitted over RF must remain intelligible and not intentionally obscured.

    At the same time, modern systems require:

    • Identity
    • Authentication
    • Contact routing
    • Service permissions (like SMS gateways)

    These two realities create a natural tension:

    • We need identity to route messages intelligently
    • But we cannot expose personal data over RF

    The Solution: A Dual-Layer Architecture

    The EHN Directory solves this problem with a two-layer security model:

    🔒 Private Identity Layer

    This is where full user records live, including:

    • Callsign and identity mapping
    • Contact methods (email, SMS, Winlink)
    • Roles and permissions
    • Service eligibility (like SMS access)

    This layer is:

    • Encrypted
    • Access-controlled
    • Synchronized only over secure links (Internet or trusted networks)

    📡 RF Operational Layer

    This is what travels over amateur radio.

    It contains only:

    • EHN_ID (a non-personal identifier)
    • Gateway association
    • Capability flags (e.g., “can send SMS locally”)
    • Coarse region (not precise location)
    • Temporary routing and roaming data

    👉 No personal identity. No contact details.

    This ensures:

    • Legal compliance
    • Privacy protection
    • Safe over-the-air operation

    Why This Matters

    This separation is not just a technical detail — it’s a foundational design decision that enables EHN to:

    ✅ Protect Operators

    Sensitive information stays off the air and under user control.

    ✅ Stay Compliant

    All RF transmissions remain consistent with amateur radio regulations.

    ✅ Operate During Outages

    Gateways can continue functioning using secure cached data, even when disconnected from the Internet.

    ✅ Scale Across Networks

    The same identity system works across RF, IP, and hybrid environments.


    Gateway Roles in the System

    The architecture introduces three types of gateways:

    🖥️ Full Gateway

    • Holds an encrypted local copy of the directory
    • Provides services like SMS bridging
    • Continues operating offline using cached data

    📡 RF Gateway

    • Relays messages over radio
    • Broadcasts only RF-safe operational data
    • Stores no sensitive user information

    🔄 Sync Gateway

    • Reconciles updates when connectivity returns
    • Validates signatures and resolves conflicts
    • Maintains authoritative consistency

    Roaming Without Exposure

    One of the most powerful features of the EHN Directory is roaming.

    When a user moves between regions, the system does not transmit their full profile. Instead, it shares a simple, temporary update:

    • EHN_ID
    • Current gateway
    • General region
    • Expiration time

    This allows the network to route messages correctly — without exposing personal details.


    Built for the Real World

    In a real emergency or outage scenario:

    • Internet connectivity may be unavailable
    • Infrastructure may be degraded
    • Operators may be mobile

    The EHN Directory is designed to handle this:

    👉 Full gateways continue operating using cached data
    👉 RF distributes only essential routing information
    👉 Systems resynchronize when connectivity returns


    Security by Design

    The EHN Directory includes modern security practices:

    • Strong authentication (including key-based identity)
    • Encrypted storage and transport (off-RF)
    • Digital signatures for data integrity
    • Role-based access control
    • Full audit and logging capability

    At the same time, it respects the unique requirements of amateur radio:

    👉 No encryption over RF that obscures meaning
    👉 Transparent, interpretable operational messages


    A Foundation for the Future

    The EHN Directory is more than a database — it is the foundation for identity-based routing across hybrid communications networks.

    It enables:

    • Smart message delivery
    • Cross-network interoperability
    • Secure service integration (like SMS gateways)
    • Resilient, decentralized operation

    And most importantly:

    👉 It does all of this while protecting operators and respecting the spirit of amateur radio


    What’s Next

    This architecture lays the groundwork for:

    • Advanced messaging services
    • Distributed applications across RF and IP
    • Integration with existing systems like Winlink and mesh networks
    • A growing community of operators, developers, and educators

    EmergencyHam.net is building a bridge between tradition and innovation — and the EHN Directory is a critical part of that vision.

    Stay tuned as we continue to develop and expand this system.


    EmergencyHam.net — Connected when it matters most.

  • Introducing the EHN Directory: Connecting People, Roles, and Devices Across Networks

    Introducing the EHN Directory: Connecting People, Roles, and Devices Across Networks

    When we talk about building a resilient, off-grid communication system, most people immediately think about radios, mesh networks, or long-distance links.

    But there’s a deeper question:

    How does the system actually know who a message is for—and how to reach them?

    That’s where the EHN Directory comes in.


    The Problem: Messages Without Meaningful Destinations

    In traditional radio systems, communication is often tied directly to:

    • a callsign
    • a frequency
    • a specific network

    That works well—until you try to bridge multiple systems together.

    Imagine this:

    • A Meshtastic node sends a message
    • The message crosses an HF link
    • It reaches another region
    • The intended recipient is… on SMS

    Now what?

    Without a shared understanding of identity, the system can only:

    • broadcast blindly
    • or fail to deliver

    Neither is acceptable in an emergency system.


    The EHN Approach: Logical Identity First

    The EHN Directory introduces a simple but powerful idea:

    Separate identity from transport

    Instead of saying:

    • “send this to a phone number”
    • or “send this to a node ID”

    We say:

    DST=USER:mary

    Now the system can decide:

    • Is Mary on mesh?
    • Should this go via SMS?
    • Is there a better path?

    The message becomes about the person, not the network.


    Personal vs Operational Identities

    One of the key design decisions in EHN is supporting two types of identity.

    Personal Identity

    Represents an individual:

    USER:jsmith
    USER:n2dh

    Used for:

    • direct communication
    • personal coordination
    • one-to-one messaging

    Operational Identity

    Represents a function or group:

    TEAM:ops-1
    ROLE:net-control
    TEAM:shelter-2

    Used for:

    • emergency coordination
    • team communication
    • persistent roles

    Why This Matters

    In real-world operations:

    • People change roles
    • Devices fail
    • Teams rotate

    But:

    The role must remain reachable

    If “net control” changes operators, the system still needs to reach:

    ROLE:net-control

    That’s something traditional systems struggle with—and something EHN handles cleanly.


    The Missing Piece: A Stable User Identity

    Under the hood, the Directory introduces another important concept:

    Every person gets a unique internal user ID

    This ID:

    • never changes
    • is not reused
    • ties everything together

    So even if:

    • someone changes their phone
    • switches devices
    • takes on a new role

    …the system still knows it’s the same person.


    Multiple Endpoints, One Identity

    A single user might be reachable through:

    • Meshtastic node
    • SMS
    • Winlink
    • APRS
    • local network

    The Directory links all of these together.

    So when you send:

    DST=USER:jsmith

    The system can choose:

    • best path
    • fallback path
    • multiple simultaneous paths

    Verification Matters

    Of course, not all endpoints are equal.

    Before bridging into public systems like SMS, the Directory ensures:

    • the endpoint is verified
    • the user is authorized
    • the message meets policy and compliance rules

    This prevents:

    • spoofing
    • abuse
    • accidental misuse of external networks

    From Messaging to Decision-Making

    The EHN Directory doesn’t just enable delivery—it enables intelligent routing.

    The system can decide:

    • which network is currently available
    • which path is most reliable
    • how to escalate delivery if needed

    This turns a simple message system into a decision-aware communication platform.


    Real-World Example

    Emergency Scenario

    A flood sensor triggers an alert:

    DST=TEAM:ops-1

    The Directory resolves that to:

    • Meshtastic nodes in the field
    • SMS numbers for on-call staff
    • Winlink addresses for EOC

    The result:

    • immediate local alert
    • broader notification
    • durable reporting

    All from a single logical destination.


    Personal Scenario

    A field operator sends:

    DST=USER:mary

    The system determines:

    • Mary is currently reachable via SMS
    • mesh is unavailable

    The message is delivered via SMS—without the sender needing to know anything about the network.


    Why This Matters for EmergencyHam

    The EHN Directory is a key part of the bigger vision:

    • bridging amateur radio and modern networks
    • supporting both education and real-world deployment
    • enabling resilient communication in degraded environments

    It allows us to move from:

    “send a message over a network”

    to:

    “deliver a message to the right person or role, no matter what network is available”


    Looking Ahead

    The Directory opens the door to:

    • smarter routing decisions
    • automated responses
    • AI-assisted coordination
    • distributed applications

    It’s not just a feature—it’s a foundation.


    Final Thought

    In a resilient communication system, networks will fail—but identity must persist.

    The EHN Directory ensures that no matter what happens to the infrastructure:

    • people remain reachable
    • roles remain functional
    • communication continues
  • Bridging the Gap: What TPRFN Teaches Us About RF-Only Networks

    Bridging the Gap: What TPRFN Teaches Us About RF-Only Networks

    Introduction

    As interest grows in resilient, off-grid communication, several projects are beginning to move beyond theory and into real-world implementation.

    One of the most interesting is TPRFN (The Packet Radio Forwarding Network)—an effort focused on building a fully RF-based data network using packet radio and HF links.

    Their recent work on bridging Winlink with packet radio highlights something important:

    Interoperability within amateur radio is not just possible—it’s already happening.


    What TPRFN Is Doing

    The TPRFN project is building a network that connects:

    • VHF/UHF packet radio nodes
    • HF forwarding links (using modes like VARA HF)
    • messaging systems such as Winlink

    The goal is simple but powerful:

    Move messages across regions using radio-only infrastructure, without relying on the internet.

    This includes bridging between:

    • traditional packet BBS systems
    • Winlink-style email messaging

    Why This Matters

    For many years, different parts of amateur radio data communication have existed in parallel:

    • Packet radio networks
    • HF messaging systems
    • Winlink infrastructure

    But these systems have not always worked seamlessly together.

    TPRFN demonstrates that:

    • messages can move between these systems
    • HF can act as a regional or long-distance backbone
    • store-and-forward networking still has significant value

    👉 In short:

    The building blocks of a resilient RF-only data network already exist.


    What TPRFN Gets Right

    There are several important strengths in this approach:

    RF-First Design

    No reliance on internet infrastructure. Everything is designed to function over radio.

    Store-and-Forward Messaging

    Messages don’t require continuous connectivity—ideal for degraded conditions.

    Integration of Existing Systems

    Rather than replacing tools, TPRFN connects them:

    • packet radio
    • HF links
    • Winlink

    Use of Proven Technologies

    AX.25, VARA HF, and established messaging systems make the network approachable and deployable today.


    Where the Limitations Appear

    While powerful, TPRFN is focused primarily within the amateur radio domain.

    That means it does not directly address integration with:

    • mobile messaging (SMS / RCS)
    • mesh networks such as Meshtastic
    • IoT sensor systems

    Additionally:

    • message formats remain system-specific
    • routing is largely network-driven rather than abstracted
    • there is no unified message layer across systems
    • Does not appear to check message validity (not needed for Ham to ham)

    A Broader Perspective

    What TPRFN demonstrates is essential:

    We can build resilient, RF-only communication networks using existing tools.

    The next step is to ask:

    How do we extend these networks beyond amateur radio?

    This is where projects like EmergencyHam take a different approach.

    Rather than focusing only on RF transport, EmergencyHam introduces a system architecture that:

    • connects multiple communication domains
    • defines a common message structure
    • enables routing across different networks
    • integrates public and private systems
    • addresses regulatory constraints when bridging into amateur radio

    Not Competing—Extending

    It’s important to be clear:

    TPRFN and EmergencyHam are not competing ideas.

    They operate at different layers:

    ConceptFocus
    TPRFNRF transport and forwarding within amateur radio
    EmergencyHamCross-network architecture and interoperability

    TPRFN proves that RF-based forwarding networks work.

    EmergencyHam explores how those networks can be connected to:

    • mesh systems
    • mobile devices
    • sensor networks

    What This Means Going Forward

    The existence of projects like TPRFN is a strong signal:

    • there is real interest in resilient communication
    • operators are actively rebuilding RF data networks
    • the gap between systems is being addressed

    The opportunity now is to bring these efforts together into a broader framework.


    Final Thought

    TPRFN shows what is possible when we reconnect existing systems.

    The next step is to expand that idea:

    Not just connecting radios—but connecting networks.


    👉 If you’re interested in how these ideas extend into multi-network communication systems, explore the EmergencyHam architecture or join the discussion.

  • GhostNet and the Future of Off-Grid Communication: From Concept to Architecture

    GhostNet and the Future of Off-Grid Communication: From Concept to Architecture

    Introduction

    Over the past few years, one topic has consistently driven traffic and interest to the EmergencyHam website: GhostNet.

    Originally developed and shared by S2 Underground, GhostNet presents a compelling vision for resilient, off-grid communication using amateur radio. It focuses on structured, operator-driven networks that can function independently of traditional infrastructure.

    It’s a powerful idea—and an important one.

    But as interest in off-grid communication grows, so does an important question:

    What comes next?


    What GhostNet Gets Right

    GhostNet is not software. It’s not a product.

    It’s a conceptual framework—a way of organizing people, frequencies, and procedures to create a functional communication network without relying on the internet.

    At its core, GhostNet emphasizes:

    • disciplined operator participation
    • structured message passing
    • scheduled nets and regional coordination
    • use of existing radio technologies (HF, digital modes, etc.)

    This approach works—and has been proven in real-world scenarios.

    More importantly, it highlights something critical:

    Resilient communication is not just about technology—it’s about organization.


    Where the Limitations Appear

    As strong as the concept is, GhostNet also exposes some natural limitations.

    Because it is primarily operator-driven, it depends on:

    • manual coordination
    • human interpretation of messages
    • predefined schedules and procedures

    This creates challenges when trying to:

    • scale across multiple networks
    • integrate modern communication systems
    • automate routing and message handling
    • connect to mobile or IoT-based systems

    In short:

    GhostNet shows how people can build a network
    but not yet how systems can interoperate across networks


    A Broader Problem: Bridging Modern Systems

    Today’s communication landscape looks very different from when amateur radio first emerged.

    We now have:

    • mesh networks like Meshtastic
    • mobile messaging (SMS, RCS)
    • IoT sensor networks
    • IP-connected systems

    Each of these operates in its own domain, with its own assumptions.

    The challenge is no longer just building a network—it’s connecting networks together.


    Introducing a System-Level Approach

    This is where EmergencyHam takes a different path.

    Rather than focusing only on operator procedures, EmergencyHam defines a system architecture that enables:

    • identity-based communication
    • structured message formats (EMP)
    • cross-network routing and bridging
    • integration between radio, mesh, and mobile systems
    • compliance and accountability layers

    In this model:

    • a Meshtastic message can reach an SMS user
    • a sensor alert can be routed through multiple networks
    • messages can traverse different communication domains seamlessly

    👉 The goal is not to replace concepts like GhostNet—but to extend them.


    A Critical Constraint: Plain Language and Compliance

    One of the most important insights that emerged while developing this architecture is the need to handle regulatory constraints, especially when bridging into amateur radio.

    Messages on amateur radio must not obscure meaning.

    That leads to a critical requirement:

    It is not enough to decrypt a message—it must be clearly intelligible as plain language before transmission.

    To address this, EmergencyHam introduces a Content Transparency & Compliance layer, which:

    • verifies message origin and destination
    • ensures decrypted content is readable and meaningful
    • applies automated validation and policy checks
    • logs and audits all ham-bound traffic

    This transforms the system from a simple bridge into something more robust:

    a compliant, accountable communication system


    Local First, Then Networked

    Another key design principle is resilience.

    EmergencyHam assumes that:

    • networks may be unavailable
    • infrastructure may be down
    • connectivity may be intermittent

    So the system is designed to operate:

    • locally first (fully functional off-grid)
    • with optional central coordination when connectivity exists

    This includes:

    • local compliance logging
    • optional replication to central nodes
    • no dependency on external systems for core operation

    Two Approaches, One Direction

    It’s important to be clear:

    GhostNet and EmergencyHam are not in competition.

    They represent different layers of the same idea:

    ConceptFocus
    GhostNetOperator-driven communication networks
    EmergencyHamSystem-driven interoperability and integration

    GhostNet shows what is possible using disciplined human coordination.

    EmergencyHam explores how those ideas can be extended into a scalable, interoperable system architecture.


    Looking Forward

    The interest in GhostNet shows that people are actively searching for alternatives to fragile, centralized communication systems.

    That interest is growing.

    The next step is to take those ideas and build systems that:

    • integrate multiple technologies
    • operate within real-world constraints
    • scale beyond individual networks
    • remain usable in both everyday and emergency scenarios

    Final Thought

    GhostNet started an important conversation.

    EmergencyHam is one attempt to continue it.

    The future of resilient communication isn’t one network replacing another—it’s multiple systems working together.


    👉 If you’re exploring these ideas, we invite you to review the EmergencyHam architecture documents or get involved as a contributor.

  • Could JS8Call Become a Gateway for Resilient Communication Networks?

    Could JS8Call Become a Gateway for Resilient Communication Networks?

    Introduction

    As EmergencyHam.Net continues to explore ways of connecting modern communication systems with amateur radio, one question keeps coming up:

    Could JS8Call play a role as a gateway within a larger, multi-network architecture?

    JS8Call has quietly become one of the most interesting tools in the amateur radio space—particularly for weak-signal, long-distance messaging. But its potential may extend beyond keyboard-to-keyboard communication.

    This post explores where JS8Call fits today—and where it could go.


    What Makes JS8Call Different?

    Unlike many traditional digital modes, JS8Call is designed specifically for structured messaging, not just contacts.

    It supports:

    • free-text messaging
    • store-and-forward inbox behavior
    • relay between stations
    • automatic presence announcements
    • weak-signal HF communication over long distances

    This makes it more than just a digital mode—it starts to resemble a message transport layer.


    Why This Matters

    Most modern communication systems fall into one of two categories:

    • Short-range, high-speed (Wi-Fi, cellular, mesh like Meshtastic)
    • Long-range, low-speed (HF radio)

    The challenge is connecting them.

    That’s where JS8Call becomes interesting:

    It sits in the long-range messaging space, but with enough structure to be integrated into something larger.


    A Potential Role: HF Gateway Layer

    Within a system like EmergencyHam.Net, JS8Call could act as:

    An HF messaging gateway—bridging long-distance radio with other communication networks

    In this role, it would:

    • receive structured messages
    • relay them across HF
    • deliver them into other systems (mesh, SMS, etc.)
    • act as a long-haul fallback when infrastructure is unavailable

    This is not a replacement for existing systems—it’s a complementary layer.


    Comparison: Where JS8Call Fits

    SystemRoleStrength
    MeshtasticLocal meshOff-grid, short-range communication
    MeshCoreLocal mesh (alt)Experimental mesh networking
    APRSTactical messagingWide adoption, simple data
    WinlinkFormal messagingEmail-style communication, structured traffic
    JS8CallHF messagingLong-range, weak-signal text and relay
    SMSPublic accessUbiquitous endpoint access

    👉 The key insight:

    JS8Call fills the long-range messaging gap between local mesh systems and global communication.


    The Opportunity

    JS8Call already has several features that make it a strong candidate for gateway integration:

    • structured messaging model
    • relay and inbox capabilities
    • weak-signal performance
    • growing community adoption

    With the addition of a system layer (like EMP in EmergencyHam.Net), it could:

    • participate in cross-network routing
    • carry messages between regions
    • act as a resilient fallback path
    • integrate with non-radio systems

    The Challenge: More Than Just Connectivity

    However, integrating JS8Call into a broader system introduces important considerations:

    • message structure compatibility
    • routing logic across networks
    • automation vs operator control
    • regulatory compliance (plain language requirements)
    • audit and traceability

    In particular:

    Any system bridging into amateur radio must ensure messages are intelligible, attributable, and compliant before transmission.

    This is where architectural layers like Content Transparency & Compliance become essential.


    A Thought, Not a Direction (Yet)

    To be clear:

    This is not a proposal to replace or redefine how JS8Call is used today.

    It’s an exploration of a possibility:

    What if tools like JS8Call could become part of a broader, interoperable communication system?


    Looking for Feedback

    This is an early-stage idea.

    If you are part of the JS8Call community, we would be very interested in your thoughts:

    • Does this align with how you see JS8Call being used?
    • Would gateway-style integration be useful or undesirable?
    • Where would this add value—or create problems?

    Final Thought

    JS8Call already demonstrates what is possible with weak-signal communication and structured messaging.

    The question is not whether it works—it clearly does.

    The question is:

    How far can it go when connected to other systems?


    👉 If you’re interested in this direction, or working on similar ideas, we’d welcome your feedback and collaboration.

  • Bridging Encrypted Networks to Amateur Radio: A Necessary Constraint, Not a Limitation

    Bridging Encrypted Networks to Amateur Radio: A Necessary Constraint, Not a Limitation

    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.

  • From Idea to Reality: EmergencyHam.Net Starts to Take Shape

    From Idea to Reality: EmergencyHam.Net Starts to Take Shape

    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.

  • Bridging Meshtastic to SMS/RCS

    Bridging Meshtastic to SMS/RCS

    A Meshtastic ↔ Phone SMS/RCS Gateway (Now Working)

    One of the first questions people ask when they discover Meshtastic is:

    “This is great… but how do I message someone who isn’t on the mesh?”

    We now have a working answer.

    We’ve built a Meshtastic ↔ Android SMS/RCS gateway, and it’s already proving to be both useful—and honestly, pretty fun.


    Why This Matters

    Meshtastic is incredibly powerful:

    • long-range
    • low power
    • infrastructure-independent

    But it has one real-world limitation:

    👉 Everyone needs to be on the mesh

    That’s fine for enthusiasts.
    Not so much for:

    • friends and family
    • local volunteers
    • the people you actually need to reach

    This gateway bridges that gap.

    Now you can:

    • send a message from the mesh
    • deliver it as a normal phone text (SMS or RCS)
    • receive replies back into the mesh

    How It Works (Simple, On Purpose)

    👉 Your contacts don’t need an app.
    👉 They don’t need a node.
    👉 They just text like normal.

    The gateway runs on an Android phone, connected via USB to a Meshtastic device running standard firmware.

    From there:

    • Incoming SMS/RCS messages are read by the phone
    • Converted into Meshtastic messages
    • Injected into the mesh
    • Mesh messages are received and sent back out as texts

    So your phone becomes a bridge:

    Phone (SMS/RCS) ↔ Gateway App ↔ USB ↔ Meshtastic Node ↔ Mesh Network


    Message Routing Options

    There are two practical ways to use it, depending on your setup:

    Shared Channel Mode

    • Messages from multiple contacts go into a shared (private) Meshtastic channel
    • Each message is tagged with a short name
    • Works well for group-style communication

    To reply:

    jackie - got it, heading over

    Simple, but effective.


    Direct / Dedicated Mode

    • A single contact maps to a specific private channel
    • Feels more like one-to-one messaging
    • No prefix needed when replying

    Tradeoffs:

    • More natural to use
    • Limited by Meshtastic channel count
    • Slightly more setup required

    The Short Name Trick (Surprisingly Important)

    SMS and RCS don’t identify people consistently:

    • SMS → phone numbers
    • RCS → long or changing names

    That gets messy fast.

    So the gateway maps each sender to a short name:

    • +12013417589 → jr
    • Johnathan M. Rodriguez (Work) → jr

    Now replies are fast and reliable:

    jr - ok, moving now

    This turns out to matter a lot—especially under pressure.


    What It Feels Like in Practice

    Reach Anyone

    You send:

    mom - running late, all good

    It goes over LoRa → hits the gateway → arrives as a normal text.

    The reply comes right back into the mesh.

    Here are a couple of screen captures showing the Meshtastic and phone screens.


    Web Client View of SMS Conversation
    Android Phone View of the SMS Conversation

    Extend Your Network (No Hardware Required)

    You can include people who don’t have:

    • a node
    • a radio
    • any special software

    That’s a huge usability win.


    EmergencyHam Use Case

    This ties directly into the bigger picture:

    • A sensor or operator sends an alert over the mesh
    • The gateway forwards it as a phone message
    • A response comes back into the system

    Simple. But powerful.


    Under the Hood (Without Getting Scary)

    It looks simple from the outside.

    Inside, there’s some real work happening:

    • message parsing and normalization
    • identity mapping
    • SMS vs RCS handling
    • routing logic
    • retry and delivery behavior

    The goal wasn’t just to make it work—but to make it:

    • predictable
    • usable under stress
    • easy to extend

    This is also the first step toward something bigger:

    👉 a common message model across multiple networks


    Why This Is Actually Fun

    This isn’t just emergency comms.

    It’s also:

    • a great experiment platform
    • a way to extend your local mesh
    • a way to show others what Meshtastic can do

    There’s something very satisfying about sending a LoRa message… and watching it land as a normal text.


    Looking for Alpha Testers

    This is working—but still early.

    We’re looking for people who want to help test and shape it.

    Ideal testers:

    • already using Meshtastic
    • have an Android phone available
    • comfortable experimenting
    • willing to give honest feedback

    What we want to learn:

    • usability
    • edge cases
    • reliability
    • real-world behavior

    What Comes Next

    This gateway is just the beginning.

    Planned next steps:

    1. Improve message handling and UI flow
    2. Add MeshCore support
    3. Introduce structured messaging (EMP V1)
    4. Bridge into APRS and Winlink

    The long-term goal:

    👉 interoperable messaging across multiple networks


    Closing Thought

    This started as a simple idea:

    “What if Meshtastic could text a phone?”

    Turns out, that opens the door to something much bigger:

    • connecting isolated networks
    • enabling real, usable traffic
    • building systems that still work when infrastructure doesn’t

    If that sounds interesting—we’d love your help testing it.


    👉 Get Involved

    Reach out via EmergencyHam.net if you’d like to be part of early testing.