SVXConnectGive your operators a live window into the reflector
SVXConnect works on any secure SvxLink reflector with no server-side setup. But if you run a reflector, two small open-source services unlock a much richer experience for every SVXConnect user connecting to it — a real-time activity feed, a live map, and friendly talkgroup & callsign names. Both are MIT-licensed and run alongside your existing SvxReflector.
SvxReflector ──poll /status──▶ SVXReflectorFeed ──(live WebSocket)──┐
(Redis session TTL) │
▼
SVXConnect apps ◀── talkgroups.json / callsigns.json ── SVXReflectorPortal
SVXConnect apps ◀────────── live events (wss://, direct) ── SVXReflectorFeedThe apps connect directly to the feed's WebSocket for live events, and fetch static talkgroup / callsign metadata from the portal.
Recommended · One DNS record
Connect with a friendly domain (DNS SRV)
Instead of asking operators to remember a host and port, publish a DNS SRV record for your reflector's domain. SVXConnect looks it up automatically: users just type the domain and the app resolves the real host and port behind it. Here is the record for our reflector, be.svx.link:
_svxreflector._tcp.be.svx.link. SRV 10 50 5300 reflector.be.svx.link.
│ │ │ └─ target host running SvxReflector + the Feed
│ │ └────── port (5300)
│ └───────── weight
└──────────── priorityHow the apps resolve it
Enter be.svx.link in the app and it queries _svxreflector._tcp.<domain>, then connects to the target host and port from the SRV answer — here reflector.be.svx.link:5300, the machine running your SvxReflector and the SVXReflectorFeed.
No SRV record? Still works
If there's no SRV record for what the user typed, the app falls back to connecting directly to that host. SRV is the nicer option — it lets you keep a stable domain and move or re-port the backend without anyone reconfiguring.
Step 1 · Required for the enhanced view
SVXReflectorFeed
The feed is the heart of the enhanced experience. It runs next to your SvxReflector, polls its local /status endpoint a few times a second, tracks each talk session in Redis (24 h TTL by default), and re-broadcasts everything as a clean live stream over a WebSocket.
Every SVXConnect app opens that WebSocket and receives a continuous stream of what's happening on the reflector — so all users see the same live picture, not just their own session:
Who's talking, now
talk_start / talk_stop events the instant a key goes down or up.
Live node state
node_upsert events keep the map of repeaters and hotspots current.
Per-talkgroup activity
see which talkgroup each station is transmitting on, in real time.
How to run it
On a Debian/Ubuntu host with Python 3.11+ and Redis: drop the repo in/opt/svx-talker-ws, create a virtualenv, install aiohttp redis websockets, and run it as a systemd service pointed at your reflector's status URL. For public use, put it behind nginx + Let's Encrypt so the apps can reach it over a secure wss:// URL. Full step-by-step instructions (systemd unit, nginx config, env vars) are in the repo README.
Step 2 · Optional, adds names & metadata
SVXReflectorPortal
The feed tells the apps that talkgroup 9990 is active; the portal tells them it's called “Parrot”. It's a small Node.js service that serves your reflector's reference data as JSON — talkgroups.json, callsigns.json and config.json — which every SVXConnect app fetches to enrich the live feed.
See a live portal
Our own reflector portal at be.svx.link — the same dashboard the apps draw on.
Talkgroup names
Map talkgroup IDs to human names so users browse “Regional” or “Parrot” instead of raw numbers.
Callsign info
Attach details to callsigns — e.g. a repeater's TX/RX frequencies — shown on hover and in map popups.
Prerequisite: the portal needs the feed. It points at your SVXReflectorFeed WebSocket (UPSTREAM_WS_URL) so its own web dashboard renders the same live data — and so do the apps. Install the feed first, then the portal.
How to run it
Node.js 20+. Configure env.yaml with your feed's UPSTREAM_WS_URL, talkgroup map and callsign map, then deploy to Google Cloud Run with the included deploy.sh, or run it as a systemd service on Debian. Serve it over HTTPS and keep the feed on wss:// to avoid mixed-content blocking. The repo README covers both paths.
Get the code
Both are open-source (MIT). Start with the feed, then add the portal.
Running a reflector and want a hand?
We're happy to help you get the feed and portal wired up for your network.