mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-10-06 00:02:14 +00:00
* fix(mobile): bump iroh to 1.3.0 so a stuck relay cannot stall direct dials iroh 1.2.0 sends a connection's first datagrams to every known path one after another inside the remote-state actor, awaiting each. When the relay is unreachable its send queue fills and the actor blocks, so handshake packets for a direct path that does work (a mesh VPN address, a public IPv6) queue behind it and the dial times out. 1.3.0 sends to all paths concurrently with a bounded wait (n0-computer/iroh#4512). The desktop workspace was already on 1.3.0; the app has its own lockfile and was left behind. * fix(gateway): reach the relay through a proxy when that is the only way out iroh dials its relay with its own resolver and its own TCP, ignoring the system proxy. On a machine whose network only works through a local proxy (Clash and the like, system-proxy or TUN mode alike) that dial never succeeds, and nothing says so: phones on the same network still connect, while a phone on cellular times out, because without a relay nothing coordinates hole punching and the home router drops unsolicited inbound packets. The gateway now lists the ways out it knows of, most likely first: tty7's own http_proxy setting, the system proxy, the environment's, then direct. It starts on the first without waiting, and when the relay stays unreachable for 10s it tries the others on a throwaway endpoint, switching to the first that reaches a relay (same key, same port, so pairing codes keep working). While none does, it looks again every minute. A pairing code now names the relay only once it is actually connected; before, it named whichever relay iroh picked by latency, reachable or not. The platform proxy readers in daemon::install::proxy now also hand back the proxy as a URL, for a client that is not ureq. Claude-Session: https://claude.ai/code/session_018wE9ZRyxgWW2f55VSy9FvZ