MeshSky
Run a Feeder

MeshSky Docs

AirBridge

The gossip relay layer of the MeshSky network — sharding, peering, and propagation.

AirBridge is the connective tissue of the mesh. AirBridge nodes accept signed observations from many feeders and gossip them to peer relays so that any observation reaches every interested ControlTower in well under 200 ms.

Why a relay layer at all?

Feeders are small, mobile, often behind NAT, and frequently bandwidth-limited. ControlTowers are heavy and few. Without a middle tier, the mesh would either:

  • Force every feeder to peer with every ControlTower (impossible at scale), or
  • Force every ControlTower to peer with every feeder (also impossible).

AirBridge fixes this with a small-world overlay: every feeder peers with a handful of nearby AirBridge relays; every AirBridge gossips with a handful of nearby peers; any observation reaches the global mesh in O(log N) hops.

Geographic sharding

The planet is partitioned into a Voronoi tessellation keyed off the long-lived public keys of healthy AirBridge nodes. A feeder’s “home shards” are the relays whose Voronoi cells contain its location.

When the relay set changes (a node joins, leaves, or is partitioned away), the tessellation re-computes deterministically — every node arrives at the same map from the same membership view.

Gossip protocol

AirBridge speaks Plumtree-style epidemic gossip over QUIC:

  • Each relay maintains an eager push set (full message bodies) and a lazy push set (just message IDs).
  • A node receives a body only once; the redundant copies arrive as IDs and are discarded.
  • Missing-message gaps are repaired by lightweight pull requests.

This gives sub-200 ms global propagation with bandwidth that’s near-optimal in steady state.

Peering

By default a relay maintains:

  • 3 intra-shard peers (very low RTT, full eager push).
  • 5 inter-shard peers (cross-region, lazy push by default).
  • 1 “long link” to a randomly chosen healthy peer anywhere on Earth, for small-world connectivity.

Operators can override these with peers.targets = … in airbridge.toml.

Backpressure & bandwidth

Every peering negotiates a budget at handshake time. If a feeder or relay exceeds its budget, the receiving end signals back-pressure, and the sender drops to a lower sample rate (or higher compression) until the budget is met. The mesh degrades gracefully rather than collapsing under load.

Running an AirBridge

System requirements:

  • 2 vCPU, 2 GB RAM, 10 GB disk (for a regional relay handling ~500 feeders).
  • A public IPv4 or IPv6 address with at least one open UDP port for QUIC.
  • Symmetric 50 Mbps connectivity is comfortable; less works with tighter peering.
curl -fsSL https://get.meshsky.io/airbridge | sudo bash

Then announce yourself to the directory:

airbridge register --region pnw --contact [email protected]

Verifiability

AirBridge nodes do not have authority. They cannot rewrite observations, because every observation is signed by its origin feeder. They cannot forge MLAT solutions, because solutions carry their own signatures. The relay layer is “just plumbing” — fast, replaceable plumbing, but plumbing nonetheless.