---
type: default
---
# Initial plan

## The scope question, first

This started as "aggregator and pusher to the tablet over USB". The pushing part
may not need to exist: over USB the tablet has an IP link via RNDIS, and the
architecture already says Class B devices reaching the bus over IP connect to the
broker directly. A Flutter MQTT client can talk to mosquitto with no hop in between.

What does not go away:

| Job | Why it needs a gateway |
|---|---|
| Aggregation | Raw CAN at 500 kbps must never reach a display; something has to downsample |
| Nav HTTP proxy | Route requests are request/response and fit MQTT badly |
| Static assets | Serving the PMTiles basemap to the display |
| Non-IP transports | BT SPP and plain serial for ESP32 clients have no broker access |

So: build the aggregation and the HTTP surface. Do not build a telemetry relay for
clients that can already subscribe for themselves.

## Order

1. Static file serving for the basemap — smallest useful thing, unblocks the map.
2. Nav HTTP proxy to [svc-nav](gitea:yukart/svc-nav).
3. Aggregation and rate limiting, once there is real CAN traffic to aggregate.
4. Serial bridge, when an ESP32 client exists.