SQVL-MESH

SQVL-MESH began with one GPS marker on a phone. At version 0.12.11, it is a client-server field coordination alpha with Android and iOS applications, persistent local state, native mapping modules, its own network protocol, and isolated team rooms.

The system gives a group one operational map for positions, roles, casualty state, tactical symbols, local terrain plans, and team visibility. Internet is the primary transport because it is currently the most accessible option in the intended environments. Meshtastic and LoRa remain a future fallback for compact critical data when internet access is unavailable.

Field coordination usually depends on several disconnected tools: a voice radio, a phone with GPS, intermittent mobile internet, separate trackers, and local or paper maps. Each tool carries part of the situation, but none maintains the complete current state of the group.

SQVL-MESH brings the core coordination state into one mobile system:

The product is designed around continuity. A useful operational picture must survive a locked screen, network interruption, delayed packets, application restart, platform differences, and a change of transport.

The first build only opened a map and displayed the phone's position. The next vertical slice connected two devices through a WebSocket relay. Local SQLite storage then made accepted state durable, while typed contracts and revision rules prevented duplicate or delayed packets from replacing newer data.

The project expanded through the same architecture: participant profiles, background GPS, iOS support, reconnect recovery, MGRS navigation, casualty timers, a Tactical Symbol Engine, local KMZ import, a true-heading compass, persisted camera state, and finally protocol v3 with isolated team rooms.

This changed the product category. SQVL-MESH is no longer a tracking demo. It is becoming a platform for participants, geospatial data, and controlled team visibility.

Positioning has three explicit modes: Off, While open, and Background. A user can stop publishing a position while continuing to receive the team's state. In background mode, coordinates continue updating while the app is not visible or the screen is locked.

The map tracks coordinate age instead of treating every replayed packet as fresh. It restores camera position, zoom, pitch, and bearing after restart and supports group overview, recentering, a central reticle, MGRS copying, distance, true bearing, and speed-based ETA.

Participant profiles separate slow-changing identity from frequent position events. A role or state change has its own revision and timestamp. Other devices calculate WOUNDED, DEAD, and STALE durations locally, so the network does not transmit a timer every second.

The compass uses platform-native heading data: Android rotation-vector sensors with magnetic declination correction and iOS Core Location true heading. It was physically accepted on Android and a working iPhone 15; an older iPhone 12 was isolated as a device-level sensor or system-service failure because Apple's own Compass failed on the same hardware.

The Tactical Symbol Engine generates deterministic SVG symbols from constrained semantic inputs such as affiliation, symbol set, status, and role. The same renderer is used in participant markers, profile settings, previews, and the Symbol Configurator.

Images, arbitrary SVG, and XML never cross the network. Clients exchange compact identifiers and reconstruct the same visual locally. The symbol catalogue can therefore grow without coupling display assets to profiles, packets, or transport.

KMZ layers follow the same privacy boundary. A selected file is validated, extracted, transformed into a local 512-pixel Web Mercator tile pyramid, registered in SQLite, and rendered by MapLibre. Source files, coordinates, filenames, and generated tiles remain on the device.

The catalogue supports up to 24 local layers with progress, recovery, visibility, ordering, Go to, and deletion. Kotlin and Swift modules perform raster processing without sending large images through the React Native bridge.

The largest recent change is server-authorized separation between teams. The Android client now supports four access states:

Members receive only the profiles and positions allowed by their room. A creator can rename a team, change its password, remove a participant, or delete the room. Passwords are not stored on the phone. After authentication, the server issues a revocable opaque session stored in protected device storage.

Changing or leaving a room establishes a new generation boundary. Old profiles, positions, and markers are cleared before the new room becomes active, preventing state from one team from leaking into another.

Admin observation combines Public and private teams on one map but cannot publish a position, mutate rooms, or use creator actions. In this mode, markers identify their source team.

Protocol v3 currently runs on a separate review relay. The existing public protocol v2 route remains unchanged, so room testing cannot destabilize the earlier working path. Team Lobby has been physically accepted on Android; the iOS client is still on the previous membership model.

SQVL-MESH is a TypeScript monorepo with a shared React Native application, a Fastify and WebSocket server, typed contracts, and native Kotlin and Swift packages for KMZ and device heading.

The mobile architecture separates state ownership:

Protocol v3 adds persistent rooms and membership, member, creator, and observer roles, revocable sessions, restricted snapshots, idempotent operations, 16 KiB packet limits, rate limiting, backpressure, room and generation isolation, restart recovery, and fail-closed storage behavior.

The relay runs in an isolated Docker container behind Cloudflare Tunnel. Releases use immutable directories, atomic promotion, a retained previous version, and rollback. A test boundary confirms that 128 simultaneous connections remain active and the 129th is rejected safely; sustained load at that boundary still requires validation.

The current automated suite contains 483 passing checks across the mobile application, server, and shared contracts. The accepted Android candidate remains version 0.12.10 (53), while 0.12.11 records its completed physical acceptance and project-history finalization rather than claiming a new installable artifact.

Physical testing covers Pixel, Sony, iPhone 12, iPhone 15, locked-screen positioning, network loss and reconnect, public and private rooms, Admin observation, participant removal, room deletion, and two- and three-device isolation scenarios. The map and background positioning have also been used during a week of field operation with Android and iOS checkpoints roughly every 100 metres.

Two Wio Tracker L1 Pro nodes were tested separately. Bidirectional messages succeeded at about 400 metres and at about 550 metres with both participants on elevated ground. Links failed around 600 and 630 metres when terrain obstructed the path. These results show how strongly LoRa depends on elevation and obstacles; they are evidence from specific tests, not a promised operating radius.

SQVL-MESH is a working alpha and Android community-test candidate. The shared map, background GPS, profiles, casualty state, symbols, MGRS, compass, local KMZ layers, camera persistence, Android Team Lobby, room isolation, session recovery, and the protocol v3 review relay have been physically accepted.

It is not yet a production system. Team Lobby is missing on iOS, protocol V3 has not replaced the public relay, and the pre-public adversarial security review, sustained 128-client test, and controlled multi-team pilot remain open. Known mapping limits include iOS memory pressure on large KMZ files, incomplete native cancellation, composite-layer ordering, JPEG and rotated GroundOverlay support, and the absence of a complete offline basemap.

Meshtastic BLE is not integrated. The current radio tests validate only the hardware hypothesis, not application-level mesh delivery.

The immediate step is the pre-public adversarial security review, followed by a limited Android community test and fixes for any blocking field failures. The next engineering sequence is iOS Team Lobby, sustained load testing, monitoring, and controlled promotion of protocol V3 to the public relay.

Critical KMZ defects and the temporary Android DNS workaround must also be closed. Only after the internet product and its operational boundaries are stable will the existing transport interface be connected to Meshtastic BLE.

I own the product concept, requirements, mobile UX, system architecture, Android and iOS development, backend and protocol design, native Kotlin and Swift modules, mapping pipeline, server infrastructure, automated and physical testing, backlog, decision history, and privacy boundaries.

The project demonstrates the complete path from uncertain field requirements to a tested system: a shared mobile product, typed protocol, local operational state, server-side authority, native geospatial processing, and an honest evidence trail for what works and what still does not.