Hi all — I just open-sourced GeoMQTT, a piece of infrastructure I built and have been running for a while. It might be useful to anyone working with moving things on a map.

What it does, in one sentence

Turns Redis GEO sets into a tile-keyed MQTT topic tree, so a web or game client can follow a moving viewport just by subscribing to the tiles it can see — and unsubscribing from the ones it can't.

Why it exists

If you have a few thousand moving points and clients that only see a slice of the map at a time, the usual "websocket bridge that broadcasts everything" pattern stops scaling at the read side, not the write side. GeoMQTT uses slippy-map tiles as the routing key, so fanout costs what each client is actually looking at, not the size of the total set. A panning map literally becomes a diff against a set of tile subscriptions.

The protocol

Topic shape: geo/<set>/<z>/<x>/<y>

Wildcards (geo/vehicles/12/+/+) are MQTT-native, so the broker handles them. New subscribers get a snapshot burst (current tile contents via GEOSEARCH) followed by the live stream — so the join is consistent without a warmup phase or a replay log.

Full wire spec: PROTOCOL.md

What ships

Single Rust binary, four listeners: RESP (Redis-compatible) on :6380, MQTT/TCP on :1883, MQTT/WebSocket on :8083, HTTP/GeoJSON on :8080
Browsers connect to the WebSocket listener directly — no extra bridge
Horizontal scaling via Redis pub/sub with node-id envelopes — no extra coordination protocol
Prometheus metrics on /status — AtomicU64::fetch_add(Relaxed) at hot paths, no background ticker, no allocator hooks, no Redis round-trips on a scrape
Five clients, all in the same repo:
- TypeScript core (Node + browser)
- Leaflet adapter
- MapLibre / Mapbox GL adapter
- Unity UPM package (with 3D world-anchored ENU projection)
- Unreal plugin (UE 5.3+, built-in MQTT codec — no third-party MQTT plugin required)
Docker / docker-compose, multi-arch images on GHCR
Live demo tracking the ISS in real time

Honest project state

v0.3.0 shipped two days ago. The architecture is settled, the five clients work, the public demo has been running for a while. The repo's star count is low because this is literally the announcement post — I am not karma-farming numbers I haven't earned yet. CI runs Rust fmt + clippy + integration tests against a real Redis service, and vitest on the TypeScript clients. Releases automate Docker, npm (GitHub Packages), UPM, and binaries for Linux/macOS/Windows on x86_64 + aarch64.

Licensing

Apache-2.0 / MIT dual-licensed — the standard Rust dual-license combo, deliberately permissive. No CLA.

Where it might fit (or not)

Obvious use cases: vehicle fleets, IoT trackers, mobility dashboards, multiplayer presence, simulation visualization. I am building a world-state engine on top of it for games (GaiaWM, talk at GDC in June), but that is a separate project — GeoMQTT itself is general-purpose infrastructure and was designed to stand on its own.

It is not the right tool if you need:

Delivery guarantees per message (the broker is QoS 0; the design assumes the next move event corrects a missed one)
A built-in object schema (the obj:* Redis hashes are arbitrary KV — clients render whatever attributes they get)
Retained messages on tile topics (the snapshot-on-subscribe burst replaces them and is more accurate, since Redis is the truth)

These are stated tradeoffs, not roadmap gaps.

What I'd like back

Try the live demo, point a client at it, tell me where the abstractions break for your shape. The cleanest pull requests usually start as "this didn't fit my use case".

u/Crow-Strict