Web Access

Web Access

AudioHub can serve the same interface on a separate port, so a browser on a phone, a tablet or another computer can drive it with nothing installed.

It is off by default, and the switch that would expose it to the network is locked on "local only". This page explains what the feature does, and — the part worth reading — why that lock exists rather than being a to-do.

---

What it is

Default port	47800/TCP, changeable, range 1024–65535
Served by	the app, not the audio service
Relationship to audio	none — this port carries no media and is not the control port
Lifetime	tied to the app window process: quit the UI from the tray and the port closes, while audio keeps running
Contents	the identical UI bundle the desktop window renders

The page does not receive credentials in its URL. It asks the app for connection parameters over a same-origin GET /ipc-endpoint once it has loaded, so there is no token sitting in your address bar, your history, or the referrer header of anything you click.

When the interface is opened this way, three settings become read-only: the enable switch, the port, and "local only". Otherwise a single misclick from the browser would close the very door you are standing in.

---

Why "local only" is locked

Local only means the port is bound to 127.0.0.1. Not "bound everywhere and filtered by source" — actually not listening on any outward-facing address, so nothing on the LAN can reach it at all.

The switch that would turn this off is present but disabled, and the honest reason is not "not implemented yet". It is that turning it off does not produce a working remote interface, so the only thing it would accomplish is the harm.

Measured, machine to machine on one LAN:

1. The remote browser does fetch the page. Fine so far.
2. The remote browser does obtain the service's IPC token from /ipc-endpoint. Already bad, and we will come back to it.
3. The remote browser cannot connect to the audio service. The service's IPC listener is bound to loopback and nothing else. From another machine it is simply not there.
4. Opening the LAN address from the local machine does not rescue it either: browsers apply Private Network Access rules and block a page served from a LAN address when it tries to open a connection to loopback.

So the net effect of unlocking the switch, today, is step 2 and nothing else: the token goes out in the clear, and the interface still does not work.

What it would take to unlock it

The app would have to provide a second path that forwards IPC outward. That is a real feature and it is not off the table — but the moment it exists, "no authentication for now" stops being tenable. Remote control and no authentication cannot both be true. Whichever way that is resolved, it is a decision to make deliberately, not one to arrive at by flipping a switch whose label says nothing about it.

Until then, the setting is treated as locked even if a configuration file says false; the service logs one line at startup when it overrides it, rather than silently disagreeing with your config.

---

What turning it off would expose

Stated plainly, because if the lock is ever lifted this is what the warning in the UI is compressing:

• Anyone on the same network who knows the IP and port can open the interface.
• /ipc-endpoint hands them the audio service's IPC token in plain text. There is no authentication in front of it.
• That token is full control of the local audio service, for anyone holding it who can also reach loopback — another login session on the machine, or any program on it that can make an HTTP request. Pair, unpair, open and close audio paths, change settings.

It is not a read-only status page. Treat the token as a password, because that is what it is.

---

Practical notes

The port is not the audio port. Changing it cannot break a call. If binding fails the interface says so and stays off — the usual cause is another program already on that port.

Two sources for the page. In a normal build the files are embedded in the app, so what the browser gets and what the window renders are byte-identical. In a development build they may come from a directory on disk; the settings page says which, because "why does the browser look older than the window" is otherwise unanswerable.

Keyboard shortcuts do not travel. They live in the browser storage of whichever origin you opened, so the desktop window and a browser tab keep separate sets. See Settings Reference.