Open • Mesh‑friendly • Store‑and‑forward

Kestrel Amateur Radio Messaging Protocol

KAMP is an open, link‑agnostic protocol for resilient message exchange over amateur radio. It embraces slow and lossy links, favors simplicity over spectacle, and delivers what matters: traffic that gets through.

Learn More Read Drafts

Designed with mesh networking and part‑time connectivity in mind.

Why Kestrel?

  • Optimized for HF and constrained links
  • Asynchronous by design — no constant connectivity required
  • Clear operating modes: Mail, NTS, and ARES/ICS
  • Open specs and reference implementations
  • Simple enough for field use, robust enough for exercises
Open Spec Mesh Store‑&‑Forward HF‑Friendly Disaster Ops

What is KAMP?

KAMP (Kestrel Amateur Radio Messaging Protocol) is a simple, interoperable protocol for reliable, delayed‑tolerant message exchange across heterogeneous links. It defines message envelopes, addressing, acknowledgements, and indexing so that nodes can synchronize traffic when connectivity is available, not only while it is.

At a glance

  • Canonical message types (e.g., ctrl-hello-v1, ctrl-ack-v1, memo-v1)
  • Small, binary‑safe envelopes with explicit timestamps
  • Index‑based sync for efficient polling and catch‑up
  • Clear separation of content vs. transport
  • Security model compatible with signed messages and gateway policies*

*Cryptographic features are governed by jurisdictional rules for amateur radio. KAMP drafts discuss policy‑friendly options and deployment guidance.

Transport‑agnostic

Run over packet radio, TCP, LoRa, or anything that can move bytes. KAMP focuses on format and flow, not the physical layer.

Predictable & Auditable

Explicit control/ack messages and simple indexes make synchronization and operator logs straightforward.

Field‑practical

Minimize ceremony; maximize clarity. Suited for nets, events, and exercises with intermittent power and coverage.

Open Governance

A community working group steers the spec via open drafts and interoperable testbeds.

What KAMP aims to be

  • Reliable message carriage over slow or intermittent links.
  • Interoperable across independent software and hardware implementations.
  • Easy to implement from microcontrollers to laptops and servers.
  • Mode‑aware workflows for day‑to‑day notes, formal NTS traffic, and ARES/ICS messages.
  • Auditable operations with clear timestamps, routing breadcrumbs, and acknowledgements.

Design principles

  • Prefer simplicity over cleverness.
  • Be explicit—about what was sent, when, and by whom.
  • Fail soft: partial sync is better than no sync.
  • Separate concerns: content, control, and transport.
  • Make manual operation possible when automation falters.

What KAMP is not

Not a real‑time chat

KAMP is store‑and‑forward. If you need live voice/data QSOs, use modes and tools designed for synchronous operation.

Not a replacement for voice nets

It complements voice with structured messaging, receipts, and archives.

Not centralized

No single authority is required. Nodes can sync peer‑to‑peer or via gateways and hubs.

Not Internet‑dependent

Works offline and over RF‑only paths. Gateways are optional helpers, not a requirement.

Operating Modes

Mail

Everyday, informal correspondence. Think postcards and notes. Minimal ceremony; clear threading and receipts.

Subject/BodyReceiptsThreads

NTS

Formal ARRL National Traffic System messages. Preserves key fields and workflow for relay accuracy and accountability.

RadiogramCheckService Msgs

ARES / ICS

Emergency/disaster operations. Structured forms (e.g., ICS‑213) and routing suited for served‑agency workflows.

ICS FormsRoutingArchival

Software can expose one or all modes; the wire format stays consistent.

The Kestrel Working Group

The Kestrel WG shepherds the KAMP specification, coordinates interoperability testing, and publishes reference implementations and test vectors. Participation is open to operators, implementers, and served‑agency partners.

How we work

  • Open Issues & Drafts
  • Public Interop Events
  • Change Control via RFCs

Get involved

  • Join the discussion list
  • Test reference code
  • Propose improvements

Participation Links

These are placeholders—replace with live links when ready.

Looking to adopt KAMP in an exercise? Contact the WG for guidance and best practices.

Specifications & Drafts

KAMP drafts are numbered KAMP‑XXXX. Expect regular iteration as field feedback comes in.

KAMP‑0001 - Core

Terminology, envelopes, addressing, message indexes, synchronization and acknowledgements.

Read Draft

KAMP‑0002 - Plugin Registry

Specification for a registry of plugins and their metadata.

Read Draft

KAMP‑0003 - Transport Profiles

Guidance for common transports (e.g., Packet, AX.25/TCP, LoRa), framing and MTU considerations.

Read Draft

KAMP‑0004 - Signatures

Specification for message signing and verification mechanisms.

Read Draft

Schemas & Test Vectors

JSON schemas for payloads, control, filters, transports, plus binary fixtures for interop.

Browse Schemas

Get started with KAMP

Implementers and operators are welcome. Start with the core draft and a reference node, then join an interop.

Read KAMP‑0001 Download Reference

Reference Implementations

  • Python reference (spec harness, interop fixtures)
  • CLI tools for encode/decode and sync
  • Optional Reticulum/LXMF gateway

All references are experimental until KAMP‑0001 reaches v1.0.

FAQ

Is KAMP only for RF?
No. KAMP is transport‑agnostic. RF is a primary target, but IP paths and sneakernets are welcome.

Does KAMP encrypt messages?
KAMP allows signed/enveloped content strategies, but on‑air cryptography may be restricted where you operate. See the drafts for compliant practices.

Can I bridge KAMP to email or web services?
Yes, via gateways, with clear markings and policy controls. Gateways must not degrade provenance or timestamps.

How big are KAMP messages?
Small by default. Drafts include guidance for chunking, MTU limits, and compression where appropriate.