[server] Guard hark serve, install it, retire the Python server

[drycode]

hark serve has been the running service on my Studio since partway through this branch, serving both machines against the same whisper backend. This makes it the shipped one and deletes src/hark/.

First: it was a faithful port, and I checked

Run side by side against the same whisper-server, same key, same audio:

	swift	python
/health	{"status":"ok"}	identical
valid WAV	{"text":"Testing the Swift server, 123."}	identical transcript
no key / wrong key	401	identical detail
wrong Content-Type	415	identical detail
empty body	400	identical detail
silence	{"text":""}	identical — RMS gate intact

The error strings match verbatim, so the client's error mapping works unchanged.

Then: three things it dropped

server.bind did nothing. NWListener(using: .tcp, on: port) accepts on every interface regardless of config, and the log printed the requested host — so the claim was false rather than merely absent:

log:    hark listening on 127.0.0.1:8914
lsof:   TCP *:8914 (LISTEN)
laptop: 200

A single-machine install was reachable from the whole network while saying it was on loopback.

No wildcard guard. The Python server has refused 0.0.0.0 since #6 — hark's response is pasted into whatever has focus, so an endpoint on every interface lets anyone who can route here choose what gets typed. That's a remote keystroke injector, not a data leak. Porting the server without it silently undid that fix.

No body cap. The body is parsed before routing, so before the key is checked — an unauthenticated request could make the server buffer whatever Content-Length it claimed. Now 16 MB → 413.

How the bind is enforced, and why not the obvious way

requiredLocalEndpoint restricts the listener but is stricter than a BSD bind(): a connection from the server's own machine to its own tailnet address is delivered locally, doesn't match the utun endpoint, and never completes. Measured — the Studio timed out reaching its own server while the laptop got 200. That breaks single-machine-on-a-tailnet, the common case.

So the address is enforced per connection, where the security question actually lives: refuse to serve anything that didn't arrive at the configured address. An attacker gets a handshake and nothing else. Loopback is always accepted — a client on this machine is the same trust boundary whichever address it dials.

Verified with bind = 127.0.0.1: loopback 200, another machine 000 with refused a connection logged.

The installer

install-server.sh builds swift/ into ~/Applications/Hark.app and points launchd at hark serve — the same bundle install-client.sh installs, so a single-machine setup gets one copy playing both roles. Plists are rendered in shell, so the server needs no Python at all. The shared secret is created by the server on first start (KeyFile.ensure).

Two things that run surfaced:

• The install smoke test piped the binary into grep. hark with no arguments prints usage and exits 2 — correct — and under pipefail that fails the pipeline whatever grep says, so the check condemned a working binary.
• --doctor probed the configured bind address and reported the service down while it was serving the laptop fine. It probes loopback now.

The deletion, and what was ported first

Gone: src/hark/, its six pytest modules, launchd/*.template, FastAPI/uvicorn/httpx, and the wheel packaging. pyproject.toml is now a test harness — nothing imports hark, and the suite drives the installers as subprocesses.

test_launchd_config_sync.py was the drift guard and its invariants were ported, not dropped: both plists render, no placeholder survives, ports match config, whisper never leaves loopback, the plist points at the installed bundle not the build tree, no WorkingDirectory, and a wildcard bind is refused before anything is written.

Two deliberate differences, each recorded as a test:

• The server's plist carries no address, because hark serve reads config.toml directly. uvicorn needed --host baked in — precisely the two-copies-of-one-fact the drift guard existed to police.
• bind = "" falls back to loopback rather than being refused. In Python that value reached a socket API where empty spells the wildcard; here it never does, and defaulting to the safe end beats refusing.

Verification

Live on my Studio: hark serve under launchd, loopback 200, laptop 200 over the tailnet, a real utterance transcribed end to end, and --doctor 6/6. The running service was confirmed unaffected before the deletion was committed.

66 pytest, 53 SwiftPM, shellcheck.

Note the client config on the server machine should be http://127.0.0.1:<port> — loopback needs no allowPlaintext and no ATS exception. Remote clients keep the private address.