
Mesh Networking in Skytrap: Structure, Coordination, and State Sharing
Skytrap's mesh networking system is built to support autonomous interceptors operating under unreliable or degraded connectivity. It assumes that central command links may be delayed, intermittent, or temporarily unavailable, and it is designed to function under those conditions rather than treating them as edge cases.
The system can be understood through three functional categories: how the mesh is structured, how coordination is maintained, and how shared state is synchronized.
1. Mesh Structure: How Nodes Discover and Relate to Each Other
Skytrap uses a hybrid mesh architecture. A Ground Base exists and plays an organizing role, but interceptors are not dependent on it for continuous operation.
Each interceptor runs a mesh client that periodically registers its identity and geographic position with the Ground Base. The Ground Base maintains a list of active nodes and removes entries that have not been refreshed within a defined timeout window. This avoids stale topology information and ensures that only reachable assets participate in the mesh.
The mesh is not fully connected. Instead, neighbor relationships are determined by physical proximity. Using reported latitude, longitude, and altitude, the Ground Base calculates distances between nodes and assigns neighbors within a configurable range. As assets move, these relationships are recalculated. Nodes therefore communicate primarily with nearby peers, reflecting real-world constraints such as radio range and line-of-sight limitations.
Discovery and topology management are centralized for consistency and observability, but once established, the mesh does not require constant Ground Base involvement to function.
2. Coordination: Leadership Without Continuous Central Control
Certain swarm-level behaviors require coordination. Skytrap addresses this through a simplified leader election mechanism rather than a fully distributed consensus protocol.
If no leader exists, or if the current leader disappears, the Ground Base initiates an election. Among active nodes, the one with the highest node identifier is selected as leader, and a term counter is incremented to track the leadership change. All other nodes assume follower roles.
This approach deliberately avoids complex consensus mechanics such as voting rounds or replicated logs. The system assumes cooperative, non-adversarial nodes and prioritizes deterministic outcomes and fast recovery over theoretical completeness.
Leadership in Skytrap is a coordination reference rather than an absolute authority. If the leader becomes unreachable, the mesh continues operating until a new leader is elected. If the Ground Base is temporarily unavailable, existing leadership and neighbor relationships remain valid based on the last known state.
A background coordination loop on the Ground Base ensures that leadership exists when possible, updates neighbor relationships, and cleans up inactive nodes. It enforces structural integrity without dictating tactical behavior.

3. State Sharing: Synchronizing a World Model Over an Unreliable Network
To coordinate effectively, nodes must share situational state. Skytrap uses DSON, a delta-based CRDT, to synchronize its distributed world model.
Rather than repeatedly transmitting full state, nodes exchange only incremental changes. These deltas are propagated using a gossip mechanism, where each node periodically forwards updates to a subset of its neighbors. This allows information to spread through the mesh even when individual messages are lost.
To prevent long-term divergence, the system periodically performs anti-entropy synchronization. During these intervals, nodes reconcile their full state to ensure eventual consistency. This combination of frequent delta gossip and occasional full reconciliation allows the mesh to tolerate packet loss, temporary partitions, and intermittent connectivity.
The design favors bandwidth efficiency and resilience over immediacy. Gossip messages are small and frequent; full synchronization is less frequent and bounded by the size of the shared world model. The current implementation has been validated at swarm sizes of approximately one hundred nodes.
The system does not attempt to address Byzantine faults. It assumes that participating nodes behave correctly, with security mechanisms such as encrypted transport and authenticated gossip planned as future extensions.

This design philosophy makes Skytrap suitable for real-world defense applications where connectivity is unreliable, resources are constrained, and recovery must be autonomous.