Thinking ahead: the comms layer, and a polyglot edge

A direction post, not a shipped-feature post. Where the console goes next once the core is solid: resilient datalinks, gateways, a mission system, and integration through published standards. Plus the language question — why the edge goes polyglot while the core stays TypeScript.

This one is a direction post, not a shipped-feature post — everything below is designed-and-deferred, not built. I'm writing it down because the shape of the next phase is now clear, and capturing the reasoning is cheaper than rediscovering it later.

The console today is a clean operator station: multi-domain control, a real-device adapter, an honest air-gap story. The next phase is the layer underneath and around it — communications and networking — and the interesting decisions there are architectural and about language, not about any one feature.

What the next phase covers

Four capability areas, all sitting behind the existing ports:

• Resilient datalinks. A transport abstraction below the device adapter so the same asset can be reached over different bearers — local line-of-sight radio, beyond-line-of-sight links, plain IP, or a self-healing mesh — with health surfaced as telemetry and failover between them. The rest of the stack keeps seeing only normalized telemetry and commands; it never learns what the bearer is.
• Networking and gateways. Services that front a fleet or a mesh as a single reliable endpoint, plus the optional connected/cloud posture (opt-in, behind an egress allowlist — the air-gapped default stays the default).
• A mission system. Planning, tasking, execution, and dynamic replanning on top of the command pipeline — repeatable missions, not just manual control.
• Integration with existing networks. Interoperating with external command-and-control and situational-awareness systems through their published standards — open civil-aviation and tactical-awareness formats for commercial use, and the appropriate standards for government deployments. All re-authored from public specifications.

The language question

Today the whole thing is TypeScript, and that's right for an operator console and a domain model. But a comms layer parsing bytes off a hostile link, doing crypto, and pushing packets is a different job. So the edge goes polyglot — per component, behind the ports — not a rewrite. The hexagonal seam is what makes this safe: a datalink adapter can be written in anything as long as it speaks the normalized contract over a local boundary. The console doesn't care.

• Rust for the hot path — protocol parsers, framing, error-correction, and crypto-adjacent code. The deciding factor is memory safety on untrusted input. A parser reading bytes off a link an attacker can reach is the classic place a buffer overflow becomes a remote exploit; Rust removes that whole class of bug while keeping C-class performance, and its ecosystem is license-clean.
• Go for network services and gateways — the mesh/IP gateway, a telemetry bus, sync daemons. Goroutine concurrency plus single static binaries that drop cleanly into an air-gapped box.
• C/C++ for ecosystem and certification interop — the established middleware, vendor radio SDKs, real-time/embedded targets, and certified toolchains are C/C++. You link that world where it's unavoidable rather than fight it.
• TypeScript stays the core — console, domain, mission logic, orchestration. Mission planning is logic and UI, not a hot path.

If I had to pick one for the new comms-critical code: Rust. Performance with memory safety is exactly the property security-critical, network-facing code wants. I'm skipping the JVM unless I ever have to integrate an existing Java system — it's heavy for the edge and its pauses fight real-time work.

Why write this down before building it

Two reasons. The selfish one: deferring is only safe if the seams are real. The hexagonal architecture earns its keep precisely here — I can name an entire comms roadmap and not build any of it yet, because each piece has a port to slot into when its trigger arrives. Naming the plan isn't a commitment to build now; it's proof the architecture won't need surgery when I do.

The honest one: a reader should be able to tell what's running from what's planned. This is planned. Ang discipline na nagpapatotoo nito (the discipline that makes it credible) is already in place, though — license-clean dependencies, clean-room from public specs, controlled material kept out of the open tree, and a strict line between the air-gapped default and any connected mode.