An open, decentralized mesh
for aviation telemetry.

A planet-scale telemetry layer that no single company owns.

Aviation telemetry — the public stream of position, identity, and intent broadcast by every commercial aircraft over open radio bands — is one of the largest open data sources in the world. It has also, quietly, become one of the most centralized. A handful of commercial aggregators ingest from tens of thousands of volunteer feeders, normalize and resell the result, and contractually restrict redistribution.

MeshSky proposes a different shape for the same data: a federation of independently-operated gateways with end-to-end encrypted, authenticated transport, in which every operator owns what they produce and every consumer assembles the wider view at read time. The protocol is HTTPS for request/response and WSS for streaming; every payload is wrapped in an AES-256-GCM envelope keyed off a per-session secret and AAD-bound to the session ID. Reference implementations exist for all three tiers (meshsky-feeder, meshsky-airbridge, meshsky-controltower) and are released under the MIT license.

This document presents the vision, the architecture, the wire protocol, the security model, the operational economics, and the roadmap. It is intended for operators who want to run a piece of the mesh, integrators who want to consume from it, and reviewers who want to evaluate it as critical-infrastructure software.

Contributions

• A three-tier topology — feeders, AirBridge gateways, and ControlTower aggregators — that is federated rather than meshed, eliminating inter-gateway gossip and the operational complexity it brings.
• A single-byte-layout AES-256-GCM session envelope shared verbatim across all three reference repos and implementable in ~30 lines in any language with AES-256-GCM and base64url.
• A meshsky:// URI for gateway discovery that bundles a 64-hex node identity and one or more transport hints, so a feeder needs exactly one string to join a sovereign gateway.
• A license-isolated multilateration design that runs the GPLv3 wiedehopf/mlat-client and wiedehopf/mlat-server binaries as separate OS processes, leaving the MIT Node code path untouched.
• A two-tier per-aircraft history layer (in-memory ring + durable SQLite) and a multi-gateway fan-in helper that unions slices across sovereign gateways without blocking on any single failure.

Table of contents

1. 1. The case for an open mesh
2. 2. Design principles
3. 3. Architecture
   1. 3.1 Feeders
   2. 3.2 AirBridge gateways
   3. 3.3 ControlTower aggregators
   4. 3.4 Discovery: the meshsky:// URI
4. 4. The wire protocol
   1. 4.1 Sessions
   2. 4.2 The envelope
   3. 4.3 REST surface
   4. 4.4 WSS surface
   5. 4.5 Versioning
5. 5. History & multi-gateway fan-in
6. 6. Multilateration as a sidecar
7. 7. Security & threat model
8. 8. Operating economics
9. 9. Governance & the RFC process
10. 10. Open questions & roadmap
11. Appendix A. Glossary
12. Appendix B. Reference repositories
13. Appendix C. Citation

1. The case for an open mesh

Aviation telemetry was open before it was anything else. ADS-B, UAT, and Mode-S broadcasts are unencrypted by design, legal to receive in nearly every jurisdiction, and inexpensive to decode — an <$30 software-defined radio and a roof-mounted antenna are enough to participate. The volunteer community has built decoders, antennas, and trackers for two decades.

That foundation has become quietly proprietary. Most volunteer feeders today push their decoded frames into one or two commercial aggregators in exchange for a free premium account on the same site. The aggregators normalize, deduplicate, and resell the merged data to airlines, dispatchers, insurance firms, and the press. Redistribution is contractually restricted; the volunteers who produce the data cannot redistribute the merged version of it.

We do not argue that the existing aggregators are doing anything wrong — running a global aggregator is hard and expensive. We argue that the dataset is too important to live only there. Search-and-rescue, journalism, climate research, flight-school operators, hobbyist developers, and academic researchers all benefit from a redistribution-friendly alternative. So does any operator who wants to own the data they produce on the way out the door.

Why “mesh”

A single-vendor service has obvious failure modes: a billing dispute, a rate-limit, a regional outage, or a quiet term-of-service change can sever an integration overnight. A federated set of independent gateways — each operated by a different person or organization, each authoritative only for what its own feeders send it — is robust against any single one of those events. A consumer that fans reads across several gateways degrades gracefully when any one of them disappears.

Why not pure peer-to-peer

We deliberately did not build a peer-to-peer mesh. GossipSub, libp2p, QUIC overlays, and Voronoi sharding are attractive in the literature but they pay for problems MeshSky does not have. Aircraft telemetry tables are small (tens of kilobytes), update rates are modest, the network is bandwidth-asymmetric (volunteer uplinks are slow), and operators want to debug their own gateways with curl. A federated topology over plain HTTPS and authenticated WebSockets is dramatically easier to operate, audit, and extend than a peer-to-peer overlay, and gives up nothing meaningful for this workload.

2. Design principles

Five principles drive every concrete decision in the rest of the document. They are listed here so a reader can decide whether to keep going.

1. Verifiable, not trusted.

   Every payload that carries aircraft data is encrypted with a per-session AES-256-GCM key, AAD-bound to the session ID. The transport is TLS, but TLS only protects the leg between the consumer and the gateway; the GCM envelope authenticates the data itself.

2. Sovereign gateways.

   Each AirBridge holds only what its own feeders fed it. Gateways do not push aircraft data to one another. The wider view is assembled at read time by a controltower that opens sessions against several gateways in parallel and unions the answers. There is no single “source of truth” that can be compromised or coerced into rewriting history.

3. License-isolated GPL.

   Multilateration uses the battle-tested wiedehopf/mlat-client and wiedehopf/mlat-server binaries, which are GPLv3. They are invoked strictly as separate OS processes and communicate over UNIX sockets. Nothing GPL-licensed is ever linked into the MIT-licensed Node code. This is the standard mechanism for combining permissive and copyleft code without forcing a license change.

4. Outbound-only feeders.

   The feeder daemon never opens a listening port. It pushes over WSS, reconnects with full-jitter exponential backoff, and never accepts inbound connections. A volunteer running a feeder on a home network has no inbound attack surface to harden.

5. Open by default.

   The reference implementations are MIT, the docs are public, and the wire format is shared verbatim across all three repos. The project is a protocol and a set of reference implementations — not a hosted product with a permission-to-use directory.

3. Architecture

MeshSky is built as three cooperating tiers linked over plain HTTPS and authenticated WebSockets. Every tier is independently operable, and every gateway is sovereign — it sees only what its own feeders sent it. A controltower assembles the wider picture by reading from many gateways in parallel.

                     ┌──────────────────────────┐
                     │       ControlTower       │
                     │ (Cloudflare Worker + DO) │
                     └──────────┬───────────────┘
                                │ HTTPS + WSS, AES-256-GCM
                                ▼
                ┌───────────────┴───────────────┐
                │ AirBridge gateways (sovereign)│
                │  /global/aircraft  /global/stream
                │  /peers/aircraft   /global/aircraft/{hex}/track
                │  /feeder/uplink    /global/aircraft/{hex}/history
                │  + history (RAM ring + SQLite)│
                │  + optional mlat-server (GPL) │
                └───────────────┬───────────────┘
                                │ WSS, AES-256-GCM
                                ▼
                ┌───────────────┴───────────────┐
                │  Feeders (outbound-only)      │
                │  dump1090 / readsb (Beast)    │
                │  + optional mlat-client (GPL) │
                └───────────────────────────────┘

3.1 Feeders

A feeder is the front door to the mesh. It is a small, outbound-only Node daemon that runs on the same host (or the same LAN) as a Beast-protocol SDR decoder — dump1090-fa, dump1090-mutability, or wiedehopf/readsb. The daemon:

• Authenticates against an AirBridge with a bearer token, opens a session, and unwraps the per-session AES-256-GCM key with its at-rest MASTER_ENCRYPTION_KEY.
• Connects to one or more Beast TCP taps (single decoder by default, or a labeled DUMP1090_SOURCES list for multi-radio hosts) and ships every Beast frame upstream inside an AES-256-GCM envelope.
• Optionally pulls a position from gpsd for GPS-disciplined timing and reports it to the gateway over POST /feeder/receiver.
• Optionally supervises the GPLv3 wiedehopf/mlat-client as a child process and forwards its sync stream over the same encrypted WSS uplink.
• Can fan its uplink across multiple gateways concurrently — replicate for redundancy or shard for split bandwidth.

The reference image runs on a Raspberry Pi 3B+ or newer with an RTL-SDR Blog v3 and a roof-mounted 1090 MHz antenna. A single feeder uses tens of kilobits per second of upstream bandwidth even in dense traffic.

3.2 AirBridge gateways

AirBridge is the connective tissue. An AirBridge gateway is a single Node process (Fastify + a WebSocket server) that:

• Accepts encrypted WSS uplinks from many feeders at /feeder/uplink.
• Decodes Beast frames into normalized aircraft records and maintains an in-process AircraftTracker keyed by ICAO hex.
• Persists a per-aircraft history layer — a fast in-memory TrackRing (default 200 points / 30 minutes per ICAO) plus a durable SQLite store (better-sqlite3, WAL mode, default 7-day retention with hourly pruning).
• Optionally supervises the GPLv3 wiedehopf/mlat-server as a separate process and ingests its solutions over a UNIX socket.
• Serves authenticated REST snapshots (/global/aircraft, plus per-ICAO /track and /history) and a WSS push stream (/global/stream) to controltowers, all wrapped in the consumer’s per-session envelope.

Crucially, gateways do not push aircraft data to one another. There is no GossipSub, no QUIC peer overlay, no cross-gateway replication. The optional /peers/aircraft endpoint exists only so that consumers (or auditors) can pull a lightweight read-only snapshot from a peer; it is rate-limited and uses the same session/envelope contract as every other read.

A reasonable production gateway runs comfortably on 2 vCPU, 2 GB RAM, and 10 GB of disk for ~500 feeders and a 7-day history. The reference deployment terminates TLS with Caddy and ships a one-command compose.yaml.

3.3 ControlTower aggregators

ControlTower is the read-side aggregator and presentation layer. A controltower:

• Authenticates against one or more AirBridge gateways and unwraps a per-gateway session key.
• Subscribes to each gateway’s encrypted aircraft stream (or polls /global/aircraft from a Cloudflare Durable Object).
• Unions per-gateway aircraft tables and per-aircraft histories into a single answer using Promise.allSettled fan-in — a dead gateway never blocks the others.
• Surfaces partial failure explicitly via partial: true and a sources[] array rather than silently absorbing the loss.

The reference controltower deploys to Cloudflare Workers + Durable Objects with a hibernating per-DO aircraft cache that polls each gateway every five seconds. The same library can run as a long-lived Node process for a self-hosted operator.

3.4 Discovery: the meshsky:// URI

A feeder or controltower needs exactly one string to find a gateway:

meshsky://<64-hex-nodeId>?via=https://airbridge.example.com&via=wss://airbridge.example.com/global/stream

The path is the gateway’s node ID — a 32-byte SHA-256 of its long-lived identity blob, lower-case hex. Each via= is a transport hint; clients try them in order and fall back as needed. There is no central registry to register with.

4. The wire protocol

MeshSky is HTTPS for the request/response surface and WSS for the streaming surface. Every byte of aircraft data on either surface is wrapped in an authenticated AES-256-GCM envelope keyed off a per-session secret. The on-the-wire data model is JSON — not a binary frame format — because the volume is modest and the operational cost of a JSON dump beats the cost of debugging a custom binary format in the field.

4.1 Sessions

Every connection begins with the same three-step exchange.

1. Open a session

POST /auth/session HTTP/1.1
Host: airbridge.example.com
Authorization: Bearer <AIRBRIDGE_BEARER_TOKEN>

The gateway returns a fresh session:

{
  "sessionId":   "01J9...",
  "sessionToken":"<base64url>.<base64url-hmac>",
  "expiresAt":   1730000000000,
  "tier":        "pro",
  "wrappedKey":  { "alg": "aes-256-gcm", "payload": "<base64url>" }
}

The client unwraps wrappedKey with its at-rest master key (AAD = sessionId) to recover the per-session AES-256-GCM key.

2. Use the session

All subsequent REST calls and the WSS upgrade carry:

Authorization:     Bearer <sessionToken>
X-Meshsky-Session: 01J9...

3. Renew

Sessions are short-lived; clients renew by re-issuing POST /auth/session. A renewal always rotates the session key. There is no in-place key rotation without a fresh session.

4.2 The envelope

Every encrypted payload uses the same byte layout, then base64url-encoded for transport in JSON:

[ 12-byte IV ][ ciphertext ][ 16-byte GCM tag ]

• Algorithm: AES-256-GCM.
• Key: the session key from /auth/session.
• AAD: the UTF-8 bytes of the sessionId.
• IV: 12 random bytes per envelope (never reused with the same key).
• Encoding: base64url, no padding.

A REST response wrapping an envelope uses a stable shape:

{
  "encrypted":   true,
  "alg":         "aes-256-gcm",
  "payload":     "<base64url IV || ciphertext || tag>",
  "sessionId":   "01J9...",
  "generatedAt": 1730000000000
}

A WSS frame is the same envelope shipped as a single text frame. The format is identical across meshsky-feeder, meshsky-airbridge, and meshsky-controltower and is implementable in roughly thirty lines in any language with AES-256-GCM and base64url support.

4.3 REST surface

4.4 WSS surface

The streaming surface negotiates the session ID via the WebSocket subprotocol header:

Sec-WebSocket-Protocol: meshsky.v1.<sessionToken>
X-Meshsky-Session:      <sessionId>

Two endpoints carry frames inside session envelopes:

/feeder/uplink — feeder → AirBridge

/global/stream — AirBridge → ControlTower

The gateway pushes incremental encrypted snapshots whenever the aircraft table changes materially or on a heartbeat interval. Frame kinds include hello, aircraft, rotate (sent when the session is about to expire), session_expired, and insufficient_credit.

4.5 Versioning

The envelope and the WSS subprotocol are versioned together: the subprotocol string is meshsky.v1.<sessionToken>. A breaking envelope change rolls the subprotocol minor. Field-level additions to JSON payloads are non-breaking; unknown keys must be ignored. A major-version bump additionally requires a published plan for backward-compatible co-existence with the previous major — rolling forward must never require a flag day for the network.

5. History & multi-gateway fan-in

Every AirBridge keeps a per-aircraft history of the positions its feeders observed. The history layer is two-tier — a fast in-memory ring buffer for “recent breadcrumbs” and a durable SQLite store for “everything since timestamp T”. A controltower talking to several gateways unions all of their slices into one answer, so the consumer sees the full picture even though no single gateway sees the whole mesh.

What gets stored

For every accepted aircraft update, AirBridge persists one row:

• icao — 24-bit ICAO hex address.
• ts — observation timestamp (ms epoch).
• lat, lon, alt_baro, alt_geom — position.
• ground_speed, track, vertical_rate — kinematics.
• squawk, flight, on_ground — identity & status.
• position_source — "adsb" or "mlat".
• source_node_id — the AirBridge that observed it.

Updates without a usable position and without kinematic data are dropped on ingest — we never store empty rows.

In-memory ring (TrackRing)

In front of the SQLite store sits a per-ICAO ring buffer with defaults of 200 points and a 30-minute maximum age. Lazily evicted on read and on every append. This serves the cheap “give me the last N fixes” query without touching disk.

Durable store (SQLite + WAL)

The persistent layer is better-sqlite3 with:

• journal_mode = WAL — writers don’t block readers.
• synchronous = NORMAL — durable enough for telemetry, ~10× faster than FULL.
• busy_timeout = 5000 — forgive transient lock contention.
• Composite primary key (icao, ts) — natural dedupe on simultaneous writes.

A background pruner runs hourly and trims rows older than HISTORY_KEEP_DAYS (default 7).

Multi-gateway fan-in

A controltower may peer with several AirBridges at once (each sovereign, each holding only the tracks its own feeders fed it). The ControlTowerHistory helper takes an array of AirBridgeClient instances and unions their answers:

• Issues every per-gateway query in parallel via Promise.allSettled.
• A dead gateway never blocks the others.
• Failures surface in partial: true and the per-gateway sources[] array.
• Points are deduplicated by (hex, ts) and sorted oldest-first.
• The merged response is re-clamped to the requested limit.

{
  "generatedAt": 1730000000000,
  "hex":         "a12b34",
  "count":       3,
  "partial":     false,
  "sources": [
    { "nodeId": "ab-pnw-1", "ok": true, "count": 2 },
    { "nodeId": "ab-pnw-2", "ok": true, "count": 1 }
  ],
  "points": [
    { "ts": 1729999970000, "lat": 47.62, "lon": -122.35,
      "altBaro": 33000, "groundSpeed": 462, "track": 285,
      "positionSource": "adsb", "sourceNodeId": "ab-pnw-1" },
    { "ts": 1729999985000, "lat": 47.65, "lon": -122.31,
      "altBaro": 33000, "positionSource": "mlat",
      "sourceNodeId": "ab-pnw-2" }
  ]
}

6. Multilateration as a sidecar

Multilateration (MLAT) locates aircraft that don’t broadcast their own GPS position by measuring the tiny time differences with which their radio signals arrive at multiple ground stations. MeshSky uses wiedehopf/mlat-server and wiedehopf/mlat-client, which are battle-tested in the wider community ADS-B ecosystem and licensed under GPLv3.

To compose them with the MIT-licensed Node code, MeshSky runs them as separate OS processes and talks to them over UNIX sockets. Nothing GPL-licensed is ever linked into the Node code path. This is the standard, audited mechanism for combining permissive and copyleft code without forcing a license change on either side.

feeder host                                      AirBridge host
┌───────────────────────┐                        ┌────────────────────────┐
│ meshsky-feeder (MIT)  │   AES-256-GCM WSS      │ meshsky-airbridge (MIT)│
│         │             │ ◄────────────────────► │         │              │
│    UNIX socket        │                        │    UNIX socket         │
│         │             │                        │         │              │
│ mlat-client (GPLv3)   │                        │ mlat-server (GPLv3)    │
└───────────────────────┘                        └────────────────────────┘

How it works

1. A non-ADS-B aircraft (e.g. a Mode-S squitter from an older airliner) transmits a short message.
2. Four or more GPS-disciplined feeders within line-of-sight receive that message and timestamp it to within a few hundred nanoseconds.
3. On each feeder, the meshsky-feeder daemon supervises a wiedehopf/mlat-client child process that handles the timing and produces an MLAT sync stream.
4. The feeder forwards that sync stream over its existing AES-256-GCM encrypted WSS uplink — it rides the same session as Beast traffic.
5. On the AirBridge side, the gateway hands the sync stream to its own supervised wiedehopf/mlat-server over a UNIX socket. The server solves and emits MLAT positions back to the gateway.
6. Solved positions flow into the same AircraftTracker and history layer as ADS-B reports, tagged with position_source: "mlat" so downstream consumers can distinguish them.

Coverage compounds

MLAT requires a sky-visible aircraft to be in range of at least four cooperating feeders attached to the same gateway. Coverage compounds with feeder density — a single new urban feeder can light up MLAT for hundreds of square kilometers around itself, and every new feeder strengthens MLAT for everyone in range of the same gateway. Open data with positive externalities.

7. Security & threat model

MeshSky assumes a partially adversarial environment and ships a small, defensible set of mitigations rather than a long list of aspirational ones. This chapter documents both.

7.1 Threat model

• The wire is untrusted. TLS terminates at the gateway’s reverse proxy (Caddy in the reference deployment); we assume an attacker can sit on it.
• Some feeders may misbehave. A buggy or deliberately noisy feeder must not be able to corrupt the gateway or other consumers.
• Some gateways may go offline. A controltower must continue to serve from the remaining gateways.
• Bearer tokens are sensitive. Operators are responsible for protecting their bearers; the protocol is designed so that a leaked bearer compromises only the data on its sessions, not the entire mesh.

MeshSky does not today assume:

• That every observation is independently signed by the originating feeder. The current envelope authenticates the session, not the individual observation. Per-observation signatures are a tracked roadmap item (§10).
• That a public registry of feeder identities exists. Identity is per-deployment.

7.2 Mitigations in place today

Confidential, tamper-evident envelopes

Every payload that carries aircraft data — REST response or WSS frame — is wrapped in AES-256-GCM with the per-session key from /auth/session. The 16-byte authentication tag is bound to the session ID via AAD, so an envelope tampered with after encryption fails to authenticate, and an envelope replayed against a different session also fails.

Ephemeral session keys

Session keys are short-lived and never reused across sessions. A leaked session key compromises only the data exchanged on that one session; renewing the session rotates the key.

Bearer-gated session bootstrap

Opening a session requires a bearer token issued by the gateway operator. The bearer is not the encryption key — it gates the ability to get an encryption key. Operators rotate bearers independently of session keys.

Outbound-only feeders

The feeder daemon never opens a listening port. There is no inbound attack surface on the edge of the mesh, only outbound TLS connections that the feeder controls.

Sovereign gateways and graceful degradation

Gateways do not push aircraft data to each other. A compromised or adversarial gateway can lie to its own consumers, but it cannot inject data into other gateways. Controltowers fan reads across multiple gateways and surface stalls or failures explicitly via partial: true rather than absorbing them silently.

License-isolated GPL components

wiedehopf/mlat-client and wiedehopf/mlat-server run as separate OS processes and communicate over UNIX sockets. They are never linked into the MIT-licensed Node code. This composition pattern is well-trodden in the open-source community and avoids the license entanglement that in-process linkage would create.

Web-side hardening

The meshsky.io site sets a strict Permissions-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and HSTS with a long max-age and preload.

7.3 Disclosure policy

We follow coordinated disclosure:

• Email security@meshsky.io.
• We aim to acknowledge within 48 hours.
• For high-severity issues we aim for a fix or mitigation within 30 days.
• Once a fix ships we publish a public advisory crediting the reporter.
• Please do not open a public GitHub issue for security vulnerabilities.

8. Operating economics

MeshSky-the-protocol is free, forever. The MeshSky Foundation offers paid tooling for operators who want managed dashboards, premium APIs, or enterprise SLAs. This chapter documents the bandwidth and operational footprint of running a piece of the mesh, and the tiered offerings around it.

8.1 Bandwidth budgets

8.2 Reference operating cost

A volunteer feeder costs roughly $60 in hardware (Raspberry Pi 3B+, RTL-SDR Blog v3, antenna) and a single-digit kilobits-per-second sliver of a residential connection. A community-scale AirBridge gateway hosting ~500 feeders fits comfortably on a 2 vCPU / 2 GB / 10 GB VPS, which retails around $10–$20 per month from any major provider. A Cloudflare-deployed controltower runs in the free tier for low-volume workloads.

8.3 Foundation tiers

The mesh stays free. Paid tiers buy convenience and SLA, never access to the data itself.

9. Governance & the RFC process

MeshSky is a protocol and a set of reference implementations, not a hosted product. There is no admin button, no master switch, no vendor lock-in. This chapter explains how the protocol evolves and who decides what.

9.1 Stewardship

The MeshSky maintainers act as stewards of the protocol. Today that means:

• Hosting the canonical specification (the meshsky.io site and the public repos).
• Maintaining reference implementations under MIT.
• Convening the RFC process.
• Holding the meshsky.io domain and trademark.

Stewardship explicitly does not include:

• Running the network. Each gateway is independently operated.
• Approving who may join. There is no central registry to register with.
• Censoring traffic, minting identities, or rewriting other operators’ data.

A formal foundation is on the roadmap. Until then, governance is lightweight — commits and issues in the public repos.

9.2 The RFC process

Protocol changes are governed by MeshSky RFCs (Requests for Comment), modeled loosely on the IETF and Rust RFC processes:

1. Pre-RFC discussion on the public forum or chat.
2. Draft opened as a pull request to github.com/meshsky/rfcs.
3. Public comment period of at least 2 weeks for substantive changes.
4. Final comment period of 1 week signaling intent to merge.
5. Reference implementation must land before the RFC is considered “stable”.

Major-version envelope or subprotocol bumps additionally require a public plan for backward-compatible co-existence with the previous major — rolling forward should never require a flag day for the network.

9.3 Forking as a remedy

The reference code is MIT and the wire contract is documented in the open. Anyone may fork. We expect the strongest argument against any fork to be the operational cost of running and integrating the existing gateways — but if the maintainers ever stray from the principles in §2, forking is the intended remedy.

10. Open questions & roadmap

MeshSky is not finished. The protocol and the reference code are stable enough to deploy today, but several deliberate gaps are tracked publicly.

10.1 Per-observation signatures

Today the envelope authenticates the session. We want feeders to additionally sign their Beast batches with a long-lived per-feeder identity so that individual observations are verifiable end-to-end — an auditor consuming /global/aircraft from a controltower could cryptographically attribute every fix to the originating feeder, not just the gateway that relayed it. This is a non-breaking additive change to the WSS frame format.

10.2 Reputation & sybil resistance

A federated mesh that anyone can join needs a way to weight contributors by demonstrated history. The reference design will surface a per-feeder reputation score derived from coverage overlap with other feeders, MLAT solver weight, and historical uptime. The score is advisory — controltowers may use it to weight or filter, but the gateway does not silently drop low-reputation feeders.

10.3 A formal foundation

We intend to incorporate a non-profit foundation to hold the domain, trademark, and any donations from operators or integrators. The bylaws will mirror the principles in §2.

10.4 An external security audit

No external audit has shipped yet. The envelope is small enough to audit informally and the threat model is documented; we will publish results in the open when a formal audit lands.

10.5 A shared @meshsky/uri package

The meshsky:// URI parser is intentionally duplicated across the three reference repos today so any of them can consume an operator-published address without a cross-repo dependency. When the API stabilises the parser will move to a shared @meshsky/uri package and the duplicates will be removed.

10.6 Beast decoder in AirBridge

The current AirBridge counts Beast frames; full Beast decoding into normalized aircraft records is in progress and the stable wire surface (/global/aircraft) does not change as a result.

Appendix A. Glossary

ADS-B

Automatic Dependent Surveillance – Broadcast. A 1090 MHz radio protocol over which most modern aircraft broadcast their own GPS-derived position, identity, and intent.

AAD

Additional Authenticated Data. In AES-256-GCM, data that is authenticated but not encrypted. MeshSky uses the session ID as AAD to bind every envelope to its session.

AirBridge

The MeshSky gateway tier. A single Fastify+WSS process that ingests feeder uplinks, persists per-aircraft history, and serves encrypted snapshots to controltowers.

Beast

A simple TCP framing protocol used by dump1090 and readsb to expose decoded radio frames to downstream consumers. Default port 30005.

ControlTower

The MeshSky read-side aggregator and presentation tier. Reference implementation runs on Cloudflare Workers + Durable Objects.

Feeder

An outbound-only Node daemon that taps Beast frames from a local SDR decoder and ships them to one or more AirBridge gateways over an encrypted WSS uplink.

GCM

Galois/Counter Mode. An authenticated encryption mode for AES with a 16-byte authentication tag.

MLAT

Multilateration. A technique for locating non-ADS-B aircraft by measuring the time differences with which their radio signals arrive at multiple ground stations.

Mode-S

An older 1090 MHz interrogation/response protocol. Mode-S squitters are short broadcasts that include the aircraft’s ICAO address but not necessarily its position.

NodeId

A 32-byte SHA-256 of an AirBridge’s long-lived identity blob, surfaced as the lower-case hex path of its meshsky:// URI.

SDR

Software-Defined Radio. A general-purpose radio receiver whose tuning, filtering, and demodulation are performed in software. The RTL-SDR Blog v3 is the cheapest known-good MeshSky-compatible device.

Session envelope

An AES-256-GCM ciphertext plus its 12-byte IV and 16-byte tag, base64url-encoded, AAD-bound to the session ID. The single confidentiality and integrity primitive of the MeshSky protocol.

TrackRing

The in-memory per-ICAO ring buffer of recent fixes maintained by every AirBridge. Default 200 points, 30-minute maximum age.

Appendix B. Reference repositories

All four repositories are MIT-licensed. The wiedehopf/mlat-client and wiedehopf/mlat-server binaries are GPLv3 and are invoked strictly as separate OS processes via the supervisor modules in meshsky-feeder and meshsky-airbridge.

Appendix C. Citation

This whitepaper is released under CC BY 4.0. Suggested citation:

MeshSky Foundation. "MeshSky: An Open, Decentralized Mesh for
Aviation Telemetry." v1.0, May 2026.
https://meshsky.io/whitepaper/meshsky-whitepaper.pdf

BibTeX:

@techreport{meshsky2026whitepaper,
  title       = {{MeshSky: An Open, Decentralized Mesh for Aviation Telemetry}},
  author      = {{MeshSky Foundation}},
  institution = {MeshSky Foundation},
  year        = {2026},
  month       = {may},
  type        = {Whitepaper},
  number      = {v1.0},
  url         = {https://meshsky.io/whitepaper/meshsky-whitepaper.pdf}
}

Contact — General: hello@meshsky.io · Security: security@meshsky.io