Tactical chat and data strategy in TAK: GeoChat, sync, and bandwidth

Tactical chat looks deceptively simple. An operator types a short message, a teammate reads it, decisions follow. But in the TAK ecosystem that message is a structured event riding the same data bus as every position report and map marker, traversing radios and satellite links that drop without warning, reaching recipients who may have been offline for the last twenty minutes. Getting chat to behave reliably under those conditions is a data-strategy problem, not a UI problem. This article examines how tactical chat actually works inside TAK – the GeoChat message format, how messages reach disconnected clients through store-and-forward sync, how attachments are decoupled from the real-time bus, and how to keep the whole thing inside a bandwidth budget on a contested link.

GeoChat: the TAK chat message as a CoT event

GeoChat is the native chat capability in ATAK, WinTAK, and iTAK. Its defining design choice is that a chat message is not a separate protocol – it is a Cursor on Target (CoT) event, the same XML-or-binary envelope that carries everything else on the TAK bus. A GeoChat event uses the CoT type b-t-f and carries the message text, the sender's callsign and UID, the destination (a single UID, a team, or all-chat), and an optional point that anchors the message to a location on the map.

That last property is what makes GeoChat "geo." An operator can drop a message on a specific grid – "contact, this building" – and the recipient sees both the words and the exact point they describe, rendered on the same map as the unit positions. The message and its spatial context arrive as one atomic event rather than as a sentence the reader has to translate into coordinates.

Because GeoChat rides the CoT bus, it inherits the bus's transports and delivery semantics without any chat-specific networking code. On a local mesh with no server, chat is UDP multicast – every client on the segment hears it. Across a router, a federation boundary, or the public internet, chat is TLS unicast to a TAK Server that fans it out to recipients. The same message format works on a handheld radio link and on a fiber backhaul; only the transport underneath changes.

Addressing: direct, team, and all-chat

A GeoChat event encodes its destination so the network knows who should receive it. A direct message targets a single recipient UID and is delivered only to that client. A team message targets a named group – the color-coded teams ATAK uses, or a custom role grouping – and reaches every member of that team. An all-chat broadcast goes to everyone reachable on the relevant transport. The addressing lives inside the event, so the server's job is to route by UID and group membership rather than to interpret message content. This separation keeps the server simple and lets the same routing logic serve chat, alerts, and any other addressed CoT.

Store-and-forward sync: reaching the client that was offline

The single hardest assumption to abandon when you come from civilian messaging is continuous connectivity. In the field it never holds. A radio goes out of range behind a ridge; a device is powered down to conserve battery; a link saturates and starts dropping packets. If chat were fire-and-forget – sent once, delivered to whoever happens to be listening – every one of those gaps would silently swallow messages, and an operator returning to coverage would have no idea what they missed.

Store-and-forward solves this. The TAK Server maintains a per-client delivery queue keyed by client UID. When a message is addressed to a recipient who is currently unreachable, the server holds it instead of discarding it. When that client reconnects, the server replays the queued messages in order, so the operator catches up on everything sent during the outage. The mechanism is invisible to the sender – they send once, and the server takes responsibility for eventual delivery.

This is also where chat differs sharply from raw position reporting. A position report that is thirty seconds old is worthless and should be allowed to go stale and disappear; replaying old positions on reconnect just clutters the map with ghosts. A chat message, by contrast, may matter just as much an hour later. So the data strategy treats the two differently: position reports get short stale times and are not replayed, while chat gets a retention window and is replayed on reconnect. Tuning those two timers against each other is one of the core configuration decisions in a TAK deployment.

Ordering and deduplication on replay

Replaying a queue introduces two subtle correctness problems. First, ordering: messages must be replayed in the sequence they were sent, or a conversation reads as nonsense. The server preserves send order per queue and the client renders by timestamp. Second, deduplication: if a client briefly reconnects, receives part of its queue, then drops again, it must not see the same messages twice when it reconnects a third time. Every CoT event carries a UID, so clients suppress any event whose UID they have already rendered. Idempotent delivery – the same message delivered twice has the same effect as delivered once – is what makes replay safe over a flapping link.

Attachments: keeping the real-time bus light

The fastest way to ruin tactical chat is to push a multi-megabyte photo through the same channel as text. The CoT bus is built for small, frequent events; a single large payload inline will stall position updates and delay every queued message behind it. So TAK decouples attachments from the message entirely.

When an operator attaches a photo, a video clip, or a data package to a chat or mission, the file is uploaded to the TAK Server's enterprise file share – the content store behind the Mission API – and the chat event carries only a content hash and a URL reference. The recipient's client receives a lightweight event saying "there is an attachment here, identified by this hash, fetchable at this URL." The actual bytes transfer over a separate HTTP channel, on demand, only when the operator chooses to open the item.

Two properties make this work in the field. First, content-addressed deduplication: because the store keys content by hash, the same image shared by ten people is stored once and counted once against bandwidth on the upload. Second, resumability: a large attachment transfer that is interrupted by a link drop resumes rather than restarting, because HTTP range requests let the client ask only for the bytes it is missing. Neither property is possible if the file is jammed inline into a real-time CoT event.

Bandwidth discipline on contested links

Once chat, sync, and attachments are architecturally separated, bandwidth discipline becomes a matter of tuning each one against the realities of the link. The first lever is encoding. A GeoChat message expressed as CoT XML is typically 400 to 900 bytes, and most of that is envelope, not message body. TAK Server supports a protocol-buffer (protobuf) encoding of CoT that compresses a typical event down to a few hundred bytes. Enabling protobuf across a fleet is the single highest-leverage bandwidth change for chat-heavy traffic, provided every client can negotiate it – mixed fleets fall back to XML for the clients that cannot decode the binary form.

The second lever is position-report cadence. On a healthy link a one-second self-report is fine; on a saturated link it is the dominant consumer of bandwidth and it crowds out chat replay. Raising the self-report interval – and using ATAK's adaptive reporting, which slows reports when an operator is stationary – frees the link for the messages that carry decisions. Similar discipline applies to MANET and mesh deployments, where every node's traffic competes for shared airtime; the same per-node budget logic that governs mobile ad-hoc mesh networking applies directly to how much chat and position traffic a segment can sustain.

The third lever is attachment policy. Auto-download should be off on any field client behind a contested link, so attachments stay as hash-and-URL references until an operator deliberately opens one. This converts a fleet-wide bandwidth event – everyone downloading the same photo at once – into a small number of on-demand fetches by the operators who actually need the content now.

Federation and chat reach

Chat reach does not stop at one server. When two or more TAK Servers are federated, a chat message addressed across the boundary is relayed between servers and delivered to recipients on the far network – provided the federation policy permits that group and the sending UID is allowed to cross. This is how a message from a forward team reaches a higher headquarters running its own server, or how a coalition partner's operators participate in a shared all-chat. The data-strategy implication is that store-and-forward and addressing now span multiple hops: a recipient on a federated peer who is offline relies on that peer's delivery queue, not the originating server's. Designing chat addressing groups so they map cleanly onto federation policy – rather than crossing it arbitrarily – keeps reach predictable and prevents messages from leaking to networks they were never meant to reach.

Chat versus mission data sync

Tactical chat is one half of the TAK data story; persistent data sync is the other. GeoChat is ephemeral and conversational – it answers "what is happening right now." A data sync mission (a Mission or Data Package in TAK Server terms) is a persistent, versioned container of content: maps, markers, files, and a change log that subscribed clients keep synchronized. It answers "what is the current authoritative state of this operation." Most deployments run both: chat for fast coordination, missions for the shared picture and document distribution, with the same store-and-forward and federation plumbing underneath. Confidentiality of both flows depends on the transport security discussed in our piece on encrypted messaging for military field use.

Putting it together: a deployment data strategy

A coherent tactical chat strategy treats messaging, sync, and attachments as three flows with different priorities sharing one link. Chat is small, latency-sensitive, and must survive disconnection through store-and-forward. Position reporting is high-volume, disposable, and should go stale rather than replay. Attachments are large, deferrable, and belong on a separate on-demand channel with deduplication and resumability. Configure the server so these three do not compete destructively – protobuf encoding everywhere, per-client chat queues with sensible retention, short stale times for tracks, and attachment auto-download disabled at the edge.

Get those decisions right and tactical chat becomes what it should be: a reliable, low-cost coordination layer that keeps working when the link is bad and catches operators up when they return. Get them wrong and chat becomes the first casualty of a saturated network – exactly when a team needs it most.