QRVnet: Offline-First Store-and-Forward Messaging for Amateur EmComm

Status, up front. QRVnet is in design and early MVP build. The cloud side (accounts, channels, mailbox) is being built now. The RF data layer exists as a specification and a loopback-tested modem path; no QRV bundle has yet crossed a real radio path in a field trial. Everything below that says "does" describes the design; where something is a goal, a plan, or a later phase, the text says so. Nothing here is legal advice. Read the Part 97 sections with your own eyes and your club's counsel.

Summary

Many EmComm drills go the same way. Traffic flows while the internet is up. When someone pulls the plug on the RMS gateway's uplink, or two stations can't hear each other on simplex, messages get stuck in somebody's outbox, and the net papers over it with voice relays and handwritten ICS-309s.

QRVnet addresses the plumbing underneath that paperwork. It is a layer that sits on top of the gear groups already own (FM repeaters, simplex channels, hotspots, EchoLink and AllStar nodes, APRS, the internet, Starlink) and turns every participating node into a mailbox that holds and forwards traffic. Messages are addressed to a callsign, survive the absence of either party, carry NTS-style precedence, and land in a persistent shared log that a net manager can turn into an ICS-309 without retyping it from memory. The cloud is one more node with a big disk. The rule throughout is radio first, internet when available, never internet-required.

The network is designed to be self-healing in the plain store-and-forward sense. When a node, a repeater, a link or the cloud drops out, traffic keeps moving over whatever paths remain (simplex, another repeater, a LAN, the internet when it's up). Bundles that can't move yet wait on disk, and nodes resync when they reconnect. There is no central switch whose loss stops RF traffic, which is also why Starlink is welcome but never load-bearing (§4.1).

Relays don't have to be trusted, either. Signing is optional and entirely local. The Ed25519 key is generated on the operator's own device, and creating a key, signing and verifying need no server, no account and no internet connection. An operator onboarded completely off-grid can sign from their first message, and anyone holding that operator's public key can check offline that a bundle arrived intact and unaltered, however many untrusted relays carried it (§7).

The RF data layer deliberately starts with the simplest, most compatible option that works: 1200-baud AFSK through the mic and speaker audio of a stock FM radio, with FX.25 forward error correction. That trades throughput for the ability to use any FM radio and any analog repeater as a relay when it matters, including the borrowed HT and the generic 2 m machine nobody in your group controls. Faster modes are optional when hardware allows.

1. The problem: EmComm when infrastructure fails

ARRL's own framing of ARES is that amateur radio "can function completely independently of the internet and phone systems."¹ That's true of a voice net. It is much less true of the digital message systems EmComm groups now rely on for formal traffic, because most of them assume, in normal operation, that somewhere in the path there is a working internet connection and a central server.

The real failure modes in an incident are mundane:

• Partition. A neighborhood, a shelter or a county is cut off. Some stations can hear the local repeater; some can only work each other on simplex; the EOC may or may not have backhaul.
• Asynchrony. The shelter operator is on the air at 0900; the EOC radio room is staffed at 1100. Nobody is on at the same time as anybody else for long.
• Heterogeneous gear. A volunteer shows up with a 15-year-old HT and a phone. A served agency has a Starlink dish and a laptop. The repeater on the ridge belongs to a club that isn't part of your ARES group.
• Accountability. After the incident the served agency wants to know what was passed, when, by whom, and whether it was delivered. The answer is usually a stack of paper and a few people's sent-items folders.

1.1 What Winlink does well, and where it hurts

Winlink deserves respect. It's an all-volunteer system run by the Amateur Radio Safety Foundation, with over a thousand gateway stations,³ an openly published message structure and forwarding protocol (B2F),² radio-only forwarding for internet outages,³ forms that served agencies recognize, and a long track record. It is also used by SHARES on government frequencies.³ Nothing in this paper argues you should stop training on it. Anyone who has run it under drill conditions knows where it chafes, and those pain points come from the architecture.

Winlink is CMS-centric by design. In conventional operation a client connects by radio to an RMS gateway, the RMS connects over the internet to a Common Message Server, and the CMS is the central repository where messages wait until the recipient connects.⁴ B2F itself is an extension of the FBB BBS forwarding protocol, oriented around a client-server session that proposes, accepts and transfers batches of messages.² That design is efficient when the internet is up. It is also why conventional Winlink is, operationally, internet email with a radio last mile.

Radio-only and Hybrid operation exist, and they work under separate rules. The Hybrid Network lets RMS gateways forward radio-only traffic among themselves toward a user's chosen Message Pickup Stations (MPS) when the internet is gone.³ As originally announced, RMS-to-RMS forwarding in that network runs on HF via Pactor 2/3/4 under RMS Trimode, and users pick their MPS with a setup tool in RMS Express (now Winlink Express).³ Winlink's own traffic-handler guide is blunt about the gotcha: a radio-only session and a normal session are "completely separate," so if you make a normal connection you will not receive, or be notified of, radio-only mail waiting for you, and your radio-only outbox won't move. You may need two connections to transact both.⁵ That is a lot of mode-awareness to ask of a tired volunteer at hour 14.

Peer-to-peer (P2P) requires both stations on the air at the same time. P2P bypasses RMS and CMS entirely, which is exactly what you want when everything is down. But the Hybrid network's designer lists the disadvantages plainly: both stations must be on the air simultaneously, must coordinate a clear frequency, must use the same protocol, and can't reach internet addresses.⁴ Winlink's VARA FM setup guide adds that P2P messages can only go to the callsign in the To: field and only while in a P2P session with that station.⁶ There is no third station in the picture that can hold the message for the absent party and hand it over later. If the EOC isn't listening when the shelter calls, the message sits in the shelter's outbox.

Delivery is POP-style, and there is no shared persistent log. Winlink's FAQ says that when you download a message, it "is immediately deleted from the CMS"; unread messages live 21 days.⁷ Your client keeps local copies, and that's fine for a personal mailbox. But for an incident, there's no shared, server-side record of what the net passed that net control, the EC and the served-agency liaison can all look at. The ICS-309 is rebuilt from individual sent folders.

The reference client is Windows-centric. Winlink Express is supported on Microsoft Windows; on Mac and Linux, Winlink's own page says to use a virtual machine or dual boot.⁸ In fairness, there are alternatives: Pat is an open-source cross-platform client,⁹ and in September 2026 the Winlink Development Team announced a native macOS client in public beta.¹⁰ But the reference client, the forms library and most training material assume a Windows laptop, and the most popular sound-card modem, VARA, is itself a Windows program.

The fast modem is closed and licensed. VARA is a proprietary modem. The free versions are speed-limited; a $75 licence (permanent, covering VARA HF, FM and SAT) enables full speed, and organizational users like SHARES are told to contact the author.¹¹ On HF the free tier is reported by VarAC's developer to stop at speed level 5, which is 177 bps at 500 Hz and 270 bps at 2300 Hz.¹² $75 is not much money for one ham. It is a real line item for a county that wants twenty loaner kits, and a closed modem is one that you can't independently decode or fix.

Forms are a strength of Winlink, and they also add friction. They are HTML templates that live in the client and update over time, and the operator has to know which template, which version and which session type to use. The ICS-213 itself is fine; the trouble is the machinery around it (§5.4).

Situational awareness and group traffic are thin. Winlink supports multiple addressees, tactical addresses, position reports and bulletin catalogs.² What it doesn't give a net is a shared operating picture: a live roster of who is checked in, who has traffic, where stations are on a map, and a channel everyone on the net can read. Broadcast traffic is something each station pulls from a catalog, so the net never sees one shared conversation.

None of this is a knock on the people who built Winlink. It was designed in a different era, around HF and internet email, and it does that job. The problem is that local EmComm in 2026 is mostly VHF/UHF FM, mostly asynchronous, mostly partitioned, and increasingly has intermittent satellite backhaul. That calls for a different shape.

2. Why a layer over existing gear

The single most important design decision in QRVnet is that it does not ask anyone to replace anything. It is a layer over infrastructure groups already own and already know how to run.

• Repeaters stay repeaters. A QRV node pairs with a repeater controller or a radio the way an EchoLink or AllStar node does: audio in, audio out, COS, PTT. The repeater keeps its callsign, its tone, its coordinator's blessing, its trustee. No firmware flash, no new controller, no digital-capable hardware required. Analog-only nodes still get voice linking, DTMF control and spoken mailbox readback; data bursts are an opt-in flag that requires the trustee to attest they have permission.
• Simplex stays simplex. Any two stations with FM radios and a node or app with a radio interface can exchange traffic directly, and any third station that hears it can carry it further.
• EchoLink, AllStar, M17, DMR, YSF and D-STAR stay what they are. QRVnet bridges to them rather than competing with them: AllStar via the USRP channel driver out of process, DMR/YSF/D-STAR through DVSwitch (which holds the AMBE vocoder, so we don't), M17 natively as the open digital-voice interop, EchoLink through a SvxLink sidecar. IRLP comes later as a co-located integration that works inside IRLP's rules.
• APRS stays APRS. Position beacons map to APRS positions, and short texts can be bridged to APRS-IS when the operator marks them. An IGate is a trustee decision, default off. We don't dump email onto the APRS frequency.
• The internet and Starlink are opportunistic backhaul. When a node has any IP path, it syncs. When it doesn't, it keeps working on RF and LAN and catches up later. Why Starlink still isn't the backbone is spelled out in §4.1.

The reasons are practical.

1. There's no forklift upgrade in a disaster. The gear you have when the power goes out is the gear you have. A system that needs every site to buy new radios first won't be on the air when it's needed.
2. The infrastructure is not ours. Most repeaters are owned by clubs and individuals who aren't going to rip out a working controller for an experiment. A node that hangs off the side of their system, behaves like a polite EchoLink node, and can be unplugged in thirty seconds is something a trustee can say yes to.
3. Every existing network has users we want to reach. The goal is that a message can originate on an app, cross a simplex hop, ride an analog repeater, go out over Starlink (when that path is up, §4.1) and land in someone's internet inbox, and that the voice side can link a QRV channel to an AllStar node or an M17 reflector without anybody on the far end changing anything.

3. Why AFSK over plain FM audio

The RF data layer's default modem is 1200-baud Bell 202 AFSK in AX.25 UI frames with FX.25 Reed-Solomon FEC, the same family of signal Direwolf and every APRS tracker speaks.¹³ It goes through the radio's microphone and speaker audio path. That is a deliberately conservative choice, and the most important one in the design. It buys five things:

• Any FM radio. AFSK lives inside the voice passband. Anything that can pass intelligible voice can pass it: a $30 HT through a cable or a sound-card interface, a mobile through its mic jack, a commercial radio repurposed for ham use. It needs no 9600-baud data port, discriminator tap, firmware change or digital-voice board.
• Any analog repeater. Because the signal is just audio, a stock analog repeater with CTCSS, pre-emphasis and a hang timer repeats it like it repeats your voice. You don't need the repeater to be digital-capable, to be on the same network, or even to know QRV exists. It needs only the owner's permission, which the node setup requires you to attest to before it will key data at all.
• Any simplex channel. Two operators on 146.52 with radios they borrowed this morning can move traffic.
• Improvised paths. Cross-band repeat on a mobile, a linked analog system, or, in the worst case, a phone held against an HT speaker is lossy but still audio. FX.25 and fragment retransmission exist to absorb exactly that kind of abuse. Acoustic coupling is a last resort, but the signal survives paths that a baseband digital mode never would.
• Open monitoring. Anyone with Direwolf or a TNC can decode the AX.25 frames; the QRV bundle format inside them is published. That matters for §97.113 and §97.309 (see §7).

3.1 The throughput trade-off

1200 baud is slow. A full frame budget of 200 bytes of payload, plus AX.25 headers and FX.25 parity, works out by arithmetic to roughly 1.7 seconds on the air before transmitter keyup delay, or about two seconds per frame. That's a few short texts, or one compact ICS-213, per burst. It's well below what you'd get from 9600-baud G3RUH packet, M17's 4FSK, or VARA FM, whose vendor quotes up to 12,750 bps narrow and 19,200 bps wide.¹¹ VARA FM also runs through ordinary FM radios' audio. It is closed and licensed, though, and a stranger's Direwolf install can't decode it.

QRVnet narrows the throughput gap in several ways:

• Compression. Bundle bodies are deflate-compressed; forms go as compact JSON.
• RF projection. Each object has an RF projection that fits the burst budget. Images go to RF as a ≤8 KB WebP thumbnail with "full image on IP"; a large email attachment goes as a notice. The full object stays in the log and moves over IP when a path exists.
• FEC and selective repeat. FX.25 corrects bit errors; missing fragments are re-requested by index rather than resending the whole bundle.
• Store-and-forward. Slowness hurts much less when nobody is waiting on a live session. A bundle that takes four bursts over ten minutes still arrives, and it arrives at every node that wanted it.
• Priority queues. Emergency traffic jumps the queue; bulk thumbnails wait.
• Faster modes are optional. A node with a 9600 port can use G3RUH; a KISS TNC or Direwolf can be the modem; M17 packet mode is planned later. AFSK is the minimum every node supports.

3.2 Being a good neighbor on a shared repeater

Data on a voice repeater is only acceptable if it never steps on voice. The channel-access rules are designed so trustees can sign off on them:

• Never start a burst while carrier (COS) is present, a voice floor is granted, or the node is transmitting voice; wait 3 s of idle after the channel drops.
• p-persistent CSMA (p = 0.25, 100 ms slots) so multiple nodes don't collide on the tail.
• Bursts ≤ 2.5 s on a repeater, ≤ 5 s on simplex.
• Hard duty-cycle cap (default 10 % per hour) and configurable quiet hours that suppress data but not voice.
• Forward selectively: always for local mailboxes, broadcast and emergency traffic; otherwise only if the addressee is local or recently heard, with a small probability of discovery forwarding.

These are starting defaults, and the field trial will tune them.

4. Why offline-first store-and-forward

The networking model borrows from delay-tolerant networking (DTN) and from forty years of packet BBS culture. The core idea is that any node holds and forwards.

• Bundles. Every message, form, position or bulletin is a self-contained bundle with a content-derived ID (a SHA-256 prefix of its canonical bytes), a sender callsign, a destination (a callsign, a channel, or broadcast), a priority and a hop limit (32 on IP, 8 on RF).
• Repeaters and hotspots as mailboxes. A node at a repeater site stores mail for its home callsigns and serves it on request: in the app, over data, or as a spoken "you have traffic" readback for analog-only stations via DTMF.
• Partition tolerance. Nothing requires an end-to-end path at send time. A bundle moves whenever any hop is available: simplex now, a repeater an hour later, Starlink tonight if that backhaul is up (§4.1).
• Dedup and gossip. Because IDs are content-derived, a node that hears the same bundle three times stores it once. Over IP, nodes exchange compact summary vectors (or a Bloom filter when the list is large) and fetch only what they lack. After a link flap, peers replay the summary and skip traffic they already hold.
• Self-healing. Nodes don't keep routing tables that must be rebuilt when something breaks; each bundle moves over whatever hops are up at the moment. If a repeater goes off the air, the same traffic can cross simplex or another machine. If a repeater-site node dies, the other nodes that heard the bundle still hold copies (Flow C, §5.3). If the EOC is off the air, a hilltop node holds its traffic (Flow A, §5.1). If the cloud or the internet is gone, RF and LAN keep working. Bundles that can't move yet wait in storage, within their retention window and hop limit, and move on when a path reappears. When nodes reconnect over IP they swap summaries and fetch only what they lack, and content IDs mean a bundle that arrives by two paths is stored once. Adding or dropping a node doesn't require updating a central route map, so there's no single node whose loss stops RF traffic. Relays don't need to be trusted for any of this: a signed bundle is checked end to end by whoever receives it (§7). Some limits apply. If no path exists at all, traffic waits until one does. Internet email and the permanent archive still need some node to reach the cloud eventually. None of this has been proven over the air yet (field trial, P7).
• Precedence. Every transmitter keeps five queues (emergency, priority, welfare, routine and bulk), following NTS precedence plus a bulk class.
• A persistent log. The cloud keeps every authenticated bundle permanently, and nodes cache with a retention window. Messages aren't deleted when read, so the mailbox works like a chat log. An ICS-309 or an after-action report becomes a query against that log instead of a search through everyone's sent folders.

Everyone with a callsign has a mailbox, even without a QRV account: traffic addressed to a callsign is stored and waits for that operator to show up on a node, in the app, or by DTMF.

4.1 Why Starlink stays a backhaul path

A Starlink kit at every EOC and shelter can look like a complete answer. Starlink is useful, and a QRV node uses it whenever it's up. Using it when it's available is a different decision from building the plan on it, and for EmComm only the first holds up. Starlink is one company's service, delivered to a powered dish under a clear sky, and each of those conditions can fail:

• Power and sky. SpaceX's spec sheets list an average draw of 75 to 100 W for the Standard kit and 25 to 40 W for the Mini, and a 110° field of view for both.³¹³² That's a continuous load on a shelter's generator or battery, and the dish needs a spot where trees, buildings and debris don't block the sky.
• Weather. An independent study of minute-level telemetry from 1,292 Starlink terminals across the continental U.S. (February to April 2025) found baseline performance was good, but 55 % of severe-weather hours showed substantial degradation (over 70 % in thunderstorms with heavy rain), with impairments and full outages lasting from minutes to over an hour.³³ Severe weather is also when EmComm groups get activated.
• Shared capacity. Capacity is shared among the users in an area. SpaceX already waitlists residential service where it's "Sold Out," and its plan terms let it, "in its sole discretion," charge a Roam Unlimited user more or limit them to the Starlink account page after 60 days in a congested, sold-out area.³⁴ A disaster area where agencies, utility crews, media and evacuees all light up dishes at once is the worst case for shared capacity.
• Account and policy. Service rides on an account, a bill and terms one company sets. Where and for whom it works is also decided centrally: in 2023 Elon Musk said SpaceX had not activated coverage to Sevastopol and declined an emergency request from Ukrainian authorities to do so;³⁵ in early 2026 Starlink deactivated terminals Russian forces had been using in Ukraine,⁴⁴ and from February 2026 terminals there worked only once they were on a government verification whitelist, updated once per day at first.⁴⁵ Whatever you think of those calls, nobody on the ground could override them.

All traffic still comes down through SpaceX's ground network. It goes up to a satellite, down to a gateway, then over terrestrial backhaul to a Starlink point of presence before it reaches the internet. Laser links let it cross the constellation to a gateway; they don't remove the need for one.³⁸ And it all runs on one operator's network core. On July 24, 2025, Starlink suffered a global outage of about 2.5 hours; SpaceX's VP of Starlink engineering, Michael Nicolls, said it "was due to failure of key internal software services that operate the core network."³⁶ SpaceX later told resellers it traced the failure to an upgrade procedure on its "ground-based compute clusters," according to PCMag.³⁷ The dishes had power and clear sky, the satellites were flying, and no traffic moved. That is a correlated failure, where one fault takes out the EOC, the shelter and the agency 300 miles away at once. A bad repeater controller takes out one repeater.

In a war, Starlink is a target, and it already has been one. The record from the Russia-Ukraine war so far:

• In early March 2022 Musk said Starlink terminals in Ukraine were being jammed and a software update countered it;⁴⁴ the Pentagon's director of electronic warfare said Starlink "had slung a line of code and fixed it" the next day.³⁹
• In April 2023 The Washington Post reported a leaked U.S. intelligence assessment that Russia had been experimenting with its Tobol electronic-warfare system to disrupt Starlink;⁴⁰ Defense Express, summarizing it, put the experiments at more than five months and a jammer near Bakhmut, with results undisclosed.⁴¹
• Ukrainian troops told Defense One in 2023 that Russian forces were locating and jamming their dishes. Each terminal then used GPS to pick its satellite, which left it exposed to GPS jamming.⁴² SpaceX has since reduced that dependence, according to a Ukrainian engineer who studies Starlink.⁴⁴
• In December 2024 a Russian defense-industry group announced "Kalinka," a direction finder it says detects Starlink terminals at up to 15 km.⁴³ In 2026 Ukraine reported growing use of what it identified as the Volna-Kupol-Garant jammer, built to blind the satellites themselves, and in June released video of a strike on one.⁴⁴

To SpaceX's credit, by most accounts the effect has been limited and local; a RUSI electronic-warfare analyst told France 24 that the Russians "have been trying really hard, but they've not had much success."⁴⁴ For EmComm planning, the relevant fact is that Starlink is in that fight at all. In any serious conflict or deliberate attack, Starlink will be a primary target, along with its gateways, its network core and the GPS so much else depends on. An EmComm plan that needs it to be up is a plan an adversary can switch off from one place.

A distributed RF network has no such place. Independently owned FM stations and repeaters, each with its own power, antenna and trustee, have no core to jam, no account to suspend and no software push that reaches all of them. A jammer near one repeater takes out that repeater's coverage; QRV traffic routes around it on simplex or another machine and catches up later, and the AFSK link needs no satellite positioning or timing. It's slow and local (§3.1), and it fails one site at a time.

So QRVnet treats Starlink like any other IP path. When a node has it, bundles sync. When it's gone (outage, congestion, a suspended account, weather or jamming), traffic keeps moving on RF and LAN and the log catches up later. That is the same self-healing behavior §4 describes for any failed link. When Starlink goes away, one path drops out and the network keeps running. Bring the dish, and plan as if it won't be there.

5. Architecture overview

The main components:

• Nodes. A Linux daemon that runs on a repeater-site computer, a hotspot-class board, or a laptop at a shelter, with a USB sound interface and a PTT/COS line. It handles analog voice linking, DTMF, the local mailbox, the optional modem, and bridges. The Android app is also a participant: it can talk to the cloud over IP and, with a radio interface, act as a small node.
• Voice channels. Numbered channels (four to six digits) behave like real repeaters: floor control with hang time, courtesy tones, CW ID on the node's transmitter, and an IRLP-style DTMF dialplan (*1000 to link a channel, 73 to drop, *99 to jump to the ARES priority channel). The app has a keypad that sends real DTMF and T9-style texting. Analog repeaters join a channel the way they'd link to EchoLink or AllStar. Codec2/M17-style digital voice is optional.
• Mailbox plane. Text, compressed images, email with attachments, bulletins, positions and forms, all as bundles. Channel-wide or individual addressing. A map of opt-in positions; an APRS-IS bridge (off by default).
• The cloud. Hosted on Cloudflare: accounts, channel floor control, the permanent log, and an email gateway that gives each licensed ham a real callsign@qrv.riftly.cloud address (subject to a provider rule cap; a dedicated mail domain is planned before that bites). If the cloud is unreachable, local repeater audio and DTMF keep working and nodes keep accepting and serving bundles from disk and from RF/LAN peers.

No single box in the diagram stops RF traffic when it fails. Lose the cloud, and the field keeps passing traffic on RF and LAN. Lose the club repeater, and stations in simplex range still reach each other. Lose the repeater-site node, and other nodes that heard the traffic still carry it. What does stop without the cloud is the internet-facing work: linked voice channels (floor control lives in the cloud), internet email in and out, and the permanent archive. That work queues and catches up when any node regains backhaul. This is the self-healing behavior from §4, seen from the diagram.

5.1 Flow A: ICS-213 from a shelter on simplex to the EOC

1. The shelter operator fills in an ICS-213 in the app (field values, not a scanned PDF). Precedence maps to bundle priority. Optionally the bundle is signed (§7).
2. The shelter node compresses the form to compact JSON. If it fits a few fragments, it goes whole; otherwise RF carries the subject, the first 500 characters and an "available in full on IP" notice, and the full form waits for an IP path.
3. The node waits for a clear channel and sends AFSK bursts on the agreed simplex frequency.
4. The EOC node, or any node in range such as a hilltop node, decodes, reassembles, verifies the signature if present, dedups and stores it. If the EOC didn't hear the first burst, a missing-fragment request recovers it; if the EOC wasn't on the air at all, the hilltop node holds it and forwards when the EOC comes up.
5. Net control sees it in the incident's queue and, with one click, appends an ICS-309 line. When either node gets backhaul, the bundle syncs to the cloud archive.

The 309 disposition is set by a human. A form in the log is not proof the served agency acted on it.

5.2 Flow B: email from the field to a served agency when backhaul is up

1. A field operator writes an email to the Red Cross liaison's ordinary address, with a photo attached.
2. If the field node has LAN or Starlink (opportunistic backhaul, §4.1), the bundle syncs straight to the cloud, which sends it as standard internet mail from the operator's callsign@ address. Outbound size is capped by the provider (5 MiB including attachments, per Cloudflare's current limits).¹⁴
3. If the field node has no backhaul, the text body moves over RF to any node that does (the attachment travels as a notice and catches up over IP), and that node syncs.
4. The reply arrives at the operator's address, is stored in the same mailbox, and is flagged as third-party traffic. Reading internet mail back onto RF is off by default and is a club/counsel decision (§7).

5.3 Flow C: a cut-off neighborhood relaying via a generic FM repeater

1. A neighborhood loses power and cell service. One ham there has an HT, a phone and a cable; a second has a mobile in the garage.
2. They can't reach the EOC on simplex, but both can hit a club's analog 2 m repeater on the ridge. The repeater isn't a QRV site; its trustee has simply agreed that QRV data bursts are allowed, and the operators' nodes are configured with that attestation.
3. Welfare and priority bundles go up the repeater in short bursts during idle time, below the duty-cycle cap. Every node that hears the repeater's output and has interest in the addressee (including the EOC node and any repeater-site node elsewhere on that machine's coverage) stores a copy.
4. The neighborhood's traffic now exists in more than one place. When any of those nodes reaches the internet, it lands in the archive and in addressees' mailboxes; replies come back the same way. None of this required any change to the repeater.

5.4 Forms, and the paperwork after the net

Winlink's forms are good and proven. The field values travel as a small XML file, a plain-text copy rides in the message body for anyone without the template, and another copy of Winlink Express renders the form cleanly from its HTML template.⁶⁷ The friction is the template layer. Templates are stored on each copy of Express and kept current by an internet auto-update, the interactive form works only inside Express, and for forms outside the standard library, sender and receiver both need the same template installed to see a form instead of plain text.⁶⁷⁶⁸ QRVnet keeps forms and drops the template layer.

A QRV form is a bundle of type=form with a kind and a set of named field values. The field lists are part of QRVnet's published spec and are built into its clients and server, so there is no template library to download or keep in sync before a drill. A field that a reader doesn't recognize is kept and ignored, not dropped, so a newer form doesn't break an older client. Only the field values go on the air, as compact deflated JSON, which is how one ICS-213 fits in a burst (§3.1). Because the form is data, the same fields can be laid out as a web page, an app screen, or plain text an operator reads to a voice or CW net. A print layout that resembles the paper form is planned. A form too large for the RF fragment budget travels as a notice carrying the subject and the first 500 characters, and the full form follows over IP (§5.1).

A form is an ordinary bundle, so it moves over every path in this paper: simplex, any analog repeater, a LAN, or the internet or Starlink when they're up. There is no special session type and no gateway connection to set up first. Forms inherit store-and-forward, dedup, precedence and self-healing (§4); a radiogram's precedence sets the bundle's priority. A form can be signed, and the signature covers its field values, so a changed field fails verification (§7). ARRL numbered-radiogram text is expanded only for display, never rewritten into the signed body.

The forms phase (P6) covers this set:

• ICS-213 General Message, the workhorse.
• ICS-205 Incident Radio Communications Plan and ICS-205A Communications List. A 205 row can point at a QRV channel number.
• ICS-211 Incident Check-In List and ICS-214 Activity Log.
• ICS-309 Communications Log, the comm log ARES and AUXCOMM operators keep. CISA's Auxiliary Communicator task book lists "Radio Logs (Form 309)" for the go-kit.⁶⁹
• ARRL radiogram, with number, precedence, handling instructions (HXA to HXG), check, address, text and signature.⁷⁰ Welfare traffic goes as a radiogram with WELFARE precedence.
• Lighter QRV net rosters and resource lists.

The ICS forms above are FEMA's.¹⁷ FEMA also publishes the ICS-213RR Resource Request Message; it isn't in the P6 list, and QRV's resource list covers tracking for now. Damage-assessment forms aren't specified yet.

Required fields are checked when a form is filed. The spec already prefills net check-ins: the roster entry takes the callsign from the talker and the time from the server. The plan extends that to forms: callsign and name from the operator's profile, the time, the current net or incident, the last reported position, and served-agency contacts from the incident's 205A.

Much of the paperwork after a net can come straight from the log. The persistent log (§4) already timestamps every bundle. Net control's check-in button (or *85 by DTMF) appends roster lines, and "log this" appends ICS-309 lines as the net runs. A scheduled net session exports an ICS-309-shaped record at the close; that export is in the MVP build. Planned for P6 and after:

• each operator's ICS-214 drafted from their own traffic and check-ins;
• end-of-shift and end-of-day packets exported as PDF and CSV for the served agency's documentation unit;
• a status trail on each message (sent, relayed, delivered, acknowledged), drawn from the log and from acknowledgement bundles.

The net manager reviews, corrects and signs the result instead of rebuilding it from memory. Two limits stay in place. An entry in the log is not proof the served agency acted on the message, and the 309 disposition column is a human's call.

6. SHARES

The SHAred RESources (SHARES) HF Radio Program, administered by CISA, provides an additional means for users with a national security and emergency preparedness (NS/EP) mission to communicate when landlines and cellular are unavailable.¹⁵ CISA describes more than 3,290 HF stations representing over 590 federal, state and industry organizations as resource contributors, nearly 500 emergency planning and response personnel as participants, and roughly 200 HF channels available to members.¹⁵ Participating stations "accept and relay messages until a receiving station is able to deliver the message to the intended recipient," which makes SHARES itself a store-and-forward system.¹⁵ SHARES runs weekly national and regional nets on Wednesdays for practice.¹⁶

SHARES is not an amateur service. CISA is explicit that "all SHARES stations are Federal government radio stations regardless of who hosts the station," licensed by the SHARES Program Office under an NTIA authorization issued to DHS.¹⁶ The channel list, net list and station directory are For Official Use Only and controlled by a non-disclosure agreement.¹⁶ Federal SHARES stations may communicate with amateur stations only in specific circumstances: with RACES stations at the direction of an emergency management official, with amateurs engaged in emergency communications on the five 60 m channels, or when necessary for the immediate protection of life and property when normal communications are unavailable.¹⁶ For Winlink traffic, SHARES permits only Pactor-3 and Pactor-4.¹⁶

QRVnet's ham network will never transmit on SHARES frequencies, and nothing in this paper suggests an amateur station should. QRV's RF is Part 97, on amateur bands, under amateur control operators.

QRVnet can help SHARES participants as a coordination and tracking layer on the ham side and the IP side, where many SHARES-registered people already overlap with ARES and RACES:

• Shared rosters and scheduled nets. The same net-control tools (check-in roster, ICS-211, scheduled net reminders) can track who in a county's ham team is also SHARES-registered and staffed today.
• Message tracking. A served agency handing traffic between an amateur path and a SHARES path needs to know what went where. QRV's log can record the handoff ("passed to SHARES station at county EOC, 1432Z") as an ICS-309 line, without carrying SHARES content on ham RF.
• ICS forms in common. ICS-213/205/205A/214 are FEMA forms both communities already use,¹⁷ and the ICS-309 comm log is standard in AUXCOMM go-kits.⁶⁹ A 205 row can point at a QRV channel number; it can also simply list the agency's own plan.
• Situational awareness. Map, roster and bulletin views over IP can give liaisons a shared picture of where amateur resources are.

QRVnet will not host SHARES FOUO material (channel lists, directories) in a general-purpose ham service or blur the line between amateur and federal stations. A SHARES workspace, if it ever exists, would be a separate, access-controlled, IP-only mode built with the SHARES Program Office's agreement, and any RF use would be on equipment and frequencies authorized by them. No such workspace exists today.

7. Compliance: Part 97, signing vs. encryption

No obscured meaning. §97.113 prohibits messages encoded for the purpose of obscuring their meaning,¹⁹ and §97.309 allows unspecified digital codes only if they are not used to obscure meaning, with records on request.²⁶ QRV's ham-mode RF is clear: AX.25 frames, a published bundle format, deflate (a public algorithm) and public keys. Anyone with Direwolf and our spec can read every byte. There is no encryption on amateur RF, and the ham mode has no switch to add it.

Local signing. Signing is optional, and everything it needs lives on the operator's own device. The app generates an Ed25519 keypair on the phone or node; the private key stays there and does not go to the cloud.⁶⁶ Making a key, signing a bundle and checking a signature are local computations that involve no server, no account and no internet connection. An operator onboarded completely off-grid can make a key and sign their traffic right away.

How signing works. When you sign, the software runs the bundle's canonical bytes through a hash function (Ed25519 uses SHA-512 internally) and uses your private key to turn the result into a 64-byte signature. The bundle carries that signature plus an 8-byte key ID, 72 bytes in all, once per bundle rather than once per RF frame. A plain hash, like the bundle's own content ID, only shows the bytes match what was hashed, and anyone who alters a message can compute a fresh hash for the new text. A signature also proves which key wrote it, because nobody without your private key can produce one that verifies against your public key.

Signing and encryption. The signature hides nothing. The message stays in the clear for anyone to read, and anyone with the sender's public key, including a monitor who has never used QRV, can check it. Our reading is that a publicly verifiable signature appended to a readable message doesn't obscure meaning under §97.113. That is our reading of the rule, and counsel should review it. Signing exists because fake from callsigns are trivial in any open relay, and in EmComm authenticity matters more than privacy.

Offline verification. Checking a signature needs only the bundle and the sender's 32-byte public key, so any receiver can do it offline. The signature covers the whole canonical bundle. The one field relays change, the remaining hop count, sits outside it, and fragments are reassembled before the check. If a bundle verifies, it is byte-for-byte what the key holder signed, whether it crossed one simplex hop or a chain of nodes, repeaters and internet links. A relay that corrupts or edits it produces a bundle that fails, and the receiver marks it invalid rather than authentic. A relay could strip the signature, but then the bundle arrives unsigned and is shown that way. Because integrity is checked end to end rather than hop by hop, relays don't need to be trusted. That is what lets the self-healing in §4 use whatever path happens to be up.

Keys and callsigns off-grid. The key ID travels in every signed bundle. A short self-signed key-announcement bundle, carrying the callsign and public key, rides the mesh like any other traffic, and nodes keep a small cache of keys they've heard. A self-signed announcement proves someone holds the key; it doesn't prove the key belongs to that callsign. Off-grid, operators can close that gap the old way, by comparing key IDs in person or reading them to each other on the air. When connectivity returns, the app can check a key against the one the operator published to the QRVnet directory, and until then it labels a key heard only on the mesh as not yet confirmed against the directory. A signature tells you the message is intact and which key wrote it. How much to trust the key depends on how it was checked.

Identification. Every transmitting node IDs under §97.119:²¹ the AX.25 source address carries the node's callsign, and voice nodes send CW ID like any repeater controller.

Control operators. Every transmission has a control operator (§97.105).¹⁸ Only licensed amateurs transmit on ham channels; anyone can listen. Unattended data nodes rely on the automatic-control provisions for RTTY/data on 6 m and shorter wavelengths (§97.221).²²

Third-party traffic. Internet email is third-party traffic, and it can be pecuniary-interest traffic. §97.115 sets the rules²⁰; §97.113 bars communications in which the licensee or control operator has a pecuniary interest, including on behalf of an employer (with narrow drill exceptions).¹⁹ That's why internet-mail readback onto RF ships off, inbound email is flagged third_party, and a club must turn it on deliberately.

Commercial LMR (Part 90). A future encrypted mode for licensed Part 90 users is a separate product. It is never bridged to amateur RF; the bridge code refuses it.

Not a 911 center. The UI says so. Life-safety calls go through the public telephone system and the served agency's procedures.

8. How QRVnet compares

The last row matters. Winlink works today, and QRVnet is a design with a build in progress. The useful question for a group is whether QRVnet is worth piloting alongside what it already runs.

9. Inspiration: standing on shoulders

Very little in QRVnet is new. Most of it is good ideas that other hams and engineers worked out, some of them decades ago, recombined for local VHF/UHF EmComm. The criticisms in §1.1 and §8 concern fit for local VHF/UHF EmComm and say nothing against the quality of these projects. Every project below works, and most will keep doing jobs QRVnet can't. This section lists what QRVnet borrows and from whom.

Packet radio, AX.25 and the packet BBS. AX.25 version 2.0 was published in 1984 by Terry Fox, WB4JFI, and TAPR's 1998 v2.2 revision describes a packet network that grew from digipeaters into HF, internet and satellite gateways.⁴⁶ We use AX.25 UI frames and callsign addressing as the RF envelope (§3). The packet BBS habit of holding mail until the addressee checks in is the heart of §4, and Winlink's B2F itself grew out of FBB BBS forwarding.²

Delay-tolerant networking (DTN). The DTN architecture (RFC 4838, 2007) grew out of work on an "Interplanetary Internet." It drops the assumption that an end-to-end path exists, keeps messages in persistent storage at each node, and borrows postal-style priority classes; the Bundle Protocol is now standardized as BPv7 in RFC 9171.⁴⁷⁴⁸ We take the model and the vocabulary: self-contained bundles, hop limits, storage everywhere, priority queues, and the working assumption that sender and receiver may never be on the air at the same time. QRV's bundle format is its own, sized for 1200 baud, but the ideas are DTN's.

APRS, and Bob Bruninga, WB4APR. Bob, who died in 2022, grew APRS from a 1982 program that plotted Navy ship positions; it was renamed APRS in 1992.⁴⁹ He insisted APRS "is not a vehicle tracking system" but "a two-way tactical real-time digital communications system" sharing what's happening in the local area, providing, in his words, "situational awareness to all operators."⁵⁰ That idea is the core of our map, roster and bulletin views. We also take 1200-baud AFSK on plain FM, position beacons, bulletins, and the lesson of his WIDEn-N "New-N Paradigm": a shared channel stays usable only if relaying is bounded.⁵¹ That's why QRV forwards selectively and caps duty cycle (§3.2).

Winlink. ARSFI's volunteers built the system served agencies know. It gives each callsign a real mailbox and an email gateway between RF and the internet, with forms people recognize, over a thousand gateway stations and use by SHARES.³ We keep those ideas: a mailbox per callsign, real callsign@ internet mail, ICS-213 and its siblings, and Winlink form import/export (P6). We drop the parts §1.1 criticizes: P2P that needs both stations on the air at once, separate radio-only and normal sessions, and mail deleted on download.

Meshtastic. Meshtastic made off-grid mesh messaging cheap and approachable: open source, community-driven, on inexpensive LoRa radios that rebroadcast what they hear, with no dedicated router.⁵² We borrow its channel model (a primary channel for routine broadcasts plus user-defined channels everyone on them can read),⁵³ the pairing of a radio node with a phone app, and position sharing on a map everyone on the mesh can see.⁵⁴ Its "managed flooding," where a node listens briefly and skips rebroadcasting if another node already did, is a reference point as we tune our own forwarding rules.⁵⁵ One difference is deliberate. QRV's ham mode never encrypts (§7).

EchoLink, AllStar/app_rpt and IRLP. These three made internet-linked repeaters ordinary. IRLP started in November 1997 to link radio systems across Canada.⁵⁶ Its inventor, Dave Cameron, VE7LTD, built it around DTMF-dialed four-digit node numbers and multi-channel reflectors.⁵⁷ EchoLink, designed by Jonathan Taylor, K1RFD, links RF nodes, PCs and phones.⁵⁹⁵⁸ AllStarLink's app_rpt turns open-source Asterisk into a repeater controller and VoIP linker.⁶⁰ QRVnet's voice side copies their best habits. Its nodes hang off a repeater the way an EchoLink or AllStar node does, channels are numbered and dialed by DTMF, and those channels behave like repeaters, with hang time, courtesy tones and CW ID (§5). AllStar and EchoLink get bridges. IRLP integration is planned but deferred (parked in §10), and it will work inside IRLP's own rules.

M17 and Codec2. Codec2 is an open-source speech codec for 700 to 3200 bit/s, built for low-bandwidth HF/VHF digital radio.⁶¹ The M17 Project, active since 2019, carries Codec2 voice in an open digital mode.⁶² We bridge M17 natively and treat Codec2/M17-style voice as the optional digital path, open on the air and decodable by anyone.

Fldigi, NBEMS and Flmsg. NBEMS proved you don't need special modem hardware or dedicated digital infrastructure to pass verified files and ICS forms. It is open-source software for nearly any computer and any analog radio, on VHF/UHF FM or HF.⁶³ §3 makes the same argument for AFSK. Flmsg's handling of ICS forms and ARRL radiograms is a model for ours.

JS8Call. JS8Call, built on the WSJT-X/FT8 engine, shows that directed, relayed and store-and-forward messages fit into a keyboard mode on weak HF paths. Heartbeats let stations discover who can hear whom.⁶⁴ QRV's recently-heard forwarding rule (§3.2) follows the same instinct.

NTS and SHARES. ARRL's National Traffic System keeps trained traffic handlers on local, section, region and area nets every day of the year.⁶⁵ QRV's five queues follow NTS precedence, and P6 includes the NTS radiogram. SHARES (§6) shows that relaying until delivery is federal practice as well as a ham habit.

If you built or maintain any of these, thank you. If we've described your work wrong, tell us and we'll fix it.

10. Roadmap

Radio first. Internet when available. Never internet-required. Every phase is held to that rule. A feature that only works with the cloud reachable is an IP convenience layered on top, and the radio path has to do the core job without it: holding, forwarding, signing and verifying traffic.

As of this draft, P1 is live at qrv.riftly.cloud: listener and ham signup, numbered channels that behave like repeaters (floor control, hang time, courtesy tones, ID), the 9999 echo channel and the DTMF dialplan. The P2 mailbox is in progress. The Android app (P3) has had its first pass. The node (P4) has a first pass in code, tested in simulation and modem loopback. Nothing has crossed a real radio path yet; that is P7a. Phases run in order, and each one's exit gate has to be met before the next starts.

After P7, work continues in parallel tracks. None of them is built yet.

• Pilots with ARES units. After P7a, drills run alongside existing Winlink and voice procedures, including partitioned scenarios, with results written up as field notes (§11).
• Apps everywhere, web parity. iOS (P7c) and desktop builds from the same Flutter tree. Anything an operator can do in an app, they can do in a browser.
• Node packaging. Install packages and ready-to-flash Pi images built around the existing systemd service, with a configuration checklist a trustee can follow.
• Local LAN mesh. Nodes on a shelter or EOC LAN find each other and sync with no internet, using the same summary-vector exchange they use with the cloud.
• Beacons and the map. APRS-style position beacons and the opt-in map, bulletins on a schedule, and an APRS-IS bridge (off by default).
• SHARES support. Rosters, handoff logging and shared ICS forms (§6). A separate IP-only SHARES workspace happens only with the SHARES Program Office's agreement.
• Open spec, open node, public API. The bundle format is already published. The node software goes open source, and the client API gets documented as a public API so clubs can build on it.
• Documentation and training. A trustee guide, a net-control guide, drill scripts and the hardware smoke test, written for volunteers.
• Parked: Winlink RMS gateway, M17 packet mode, and the IRLP adapter, built within IRLP's rules once they agree.

10.1 HF track: regional and long-haul store-and-forward

Design and roadmap; nothing in this track is built. VHF/UHF FM covers a county. HF closes the gaps between counties and states. The track follows the layer rule from §2: it uses the HF rig a ham already owns, through its audio and CAT/PTT interface, with open sound-card modems and no new radio.

HF data from 160 m through 10 m, except 60 m, falls under §97.307(f)(3). It must use a specified digital code (§97.309(a)), and any technique has to be publicly documented.²⁶ The authorized bandwidth is 2.8 kHz.²⁵ The FCC removed the old 300-baud HF symbol-rate cap and replaced it with the 2.8 kHz bandwidth limit, effective January 8, 2024.⁷¹ The 300-baud cap now survives only on 2200 m and 630 m.²⁵ The January 2026 amendment opened 5351.5 to 5366.5 kHz on 60 m. That segment carries data under a 2.8 kHz limit at 9.15 W ERP, with 100 W ERP on the four discrete channels; it is secondary and open to General class and above.⁷²²⁵ No encryption on any band (§7).

QRV's HF modem list starts with open, publicly documented modes:

• ARDOP. Open protocol; ardopcf is an MIT-licensed cross-platform implementation. Its maintainer has stopped development, so QRV treats ARDOP as a candidate and won't depend on it.⁷³
• FreeDATA. An open-source HF platform built on codec2 data modes, with a REST API. Development has slowed.⁷⁴
• Fldigi modes. PSK, MFSK, Olivia and MT63, which NBEMS groups already run.⁷⁵⁶³
• JS8. Weak-signal messaging with heartbeats, relays and store-and-forward.⁶⁴

VARA HF is widely used, but it is commercial and vendor-licensed.¹¹ It can be an operator-supplied option. It is never the default, and nothing requires it. Every mode is checked against the 2.8 kHz limit before it is enabled.

HF nodes hold and forward under the same rules as §4, retuned for scarce airtime:

• Gateways between VHF islands. A county's VHF/FM mesh hands bundles to its HF gateway. That gateway forwards them to another region's HF node, which drops them into its own local mesh as in §5. No internet sits anywhere in that chain.
• Scheduled, propagation-aware windows. Gateways meet in agreed forwarding windows and pick the band by time of day and recent results. For NVIS out to about 500 km, the reliable range is 1.8 to 8 MHz, typically 80 m at night and 40 m by day, with 60 m as a further option.⁷⁶ Automatic band and path selection uses decode history from the heard list.
• A calling frequency and a heard list. Between windows, gateways monitor a calling frequency with JS8-style heartbeats.⁶⁴ The resulting heard list drives forwarding, the same instinct as the recently-heard rule in §3.2.
• Inventory before transfer. Peers swap a summary vector or Bloom filter first (§4) and send only the bundles the other side lacks.
• Precedence first. The five queues apply, so emergency traffic leaves before routine, every window.
• Fragments that survive a fade. Large bundles go in fragments. After a fade, the receiver asks for the missing pieces (§5.1) and the transfer resumes in the next window instead of starting over.
• Custody handoff. On HF, custody acks are on by default. The sender keeps a bundle until the next node acknowledges taking custody, then drops it to cache. That is DTN's custody-transfer idea (§9).⁴⁷
• Multi-hop relay. When two gateways can't hear each other, a third that hears both carries the traffic, within the RF hop limit.
• One-to-many bulletins. A bulletin goes out once on a schedule. Receivers fill gaps by asking for fragments, with no per-station session.
• Regional HF nets. ARES gateways check in on regional nets. SHARES interop happens at the EOC, as a logged handoff (§6), never as SHARES content on amateur RF.
• Later: ALE-style linking. Scanning a channel list, sounding, and picking the best channel automatically. Hams already run open ALE nets.⁷⁷

10.2 Future phase: QRV hardware and wideband simplex data

Roadmap; nothing in this phase is built. A QRV radio runs analog FM alongside QRV's digital modes. Its key feature is on-demand wideband simplex: two radios agree on the narrow FM/AFSK link ("3 MB of imagery for you; meet on W2"), hop together to a wide channel for the transfer, then return. The narrow link remains the rendezvous and control path. An HF-capable variant or interface brings the same node software to an existing HF rig through audio, CAT and PTT.

The rules shape the channel plan:

• 33 cm (902-928 MHz) is the only home for channels around 500 kHz. §97.305(c) allows data, test and spread spectrum across the band under §97.307(f)(7), which sets no symbol-rate or bandwidth cap. §97.307(a) still requires no more bandwidth than the information rate needs.²⁴²⁵ The ARRL band plan sets aside 909-915, 915-921 and 921-927 MHz for broadband multimedia including SS, and regional coordinators' plans take precedence.³⁰ Amateurs are secondary. They must accept interference from ISM devices, can't transmit near White Sands in Texas and New Mexico or on certain segments in parts of Colorado and Wyoming, and are limited to 50 W PEP within 241 km of White Sands.²³²⁸
• Spread spectrum on 33 cm and 70 cm stays inside §97.311 and 10 W PEP (§97.313(j)), with its spreading parameters published.²⁷²⁸
• 70 cm data tops out at 100 kHz and a 56-kilobaud symbol rate (§97.307(f)(6)).²⁵ Line A, the land-mobile areas near Buffalo, Cleveland and Detroit, and the US270 50 W areas (including near Beale AFB and Otis AFB) are enforced by location.²³²⁸²⁹
• 2 m stays narrow, at 20 kHz and 19.6 kilobaud, for AFSK and rendezvous.²⁵

The radio's firmware enforces band, bandwidth, power and location limits, so the operator doesn't have to remember them at 0300.

11. Call to action

We're looking for a small number of groups to pilot this with us early:

• ARES/RACES/EmComm groups willing to run QRVnet alongside your existing Winlink and voice procedures in a drill, and tell us where it breaks. We especially want ICS-213/309 workflows and partitioned scenarios.
• Repeater owners and trustees willing to host a node on a test basis (voice linking first, data bursts only if and when you're comfortable) and to hold us to the duty-cycle and courtesy rules above.
• Net managers who want to try roster, check-in and 309 tooling on a weekly net.
• Served-agency liaisons and SHARES participants who can tell us what a coordination/tracking layer would need to be useful without stepping on federal procedures.

Sign up and get in touch through the QRVnet site: qrv.riftly.cloud.

73, and thanks for reading this far.

Wayne, KC9ZRI · Rift Software