Follow-up from the dual-interface refactor (ea2e57e on feat/enable-tunnel-flip-flag).
Current behaviour
After the dual-interface change, the Network Status page lists both interfaces by their raw types. With a single user-added TCP relay + Background Transport enabled, the user sees something like:
TCPClient — TCP Server
TCPClient — TCP Tunnel
These are one logical relay (same host:port) being shown as two unrelated TCP clients, which doesn't communicate that the second one only exists to keep the connection alive when the app is backgrounded.
What it should look like
Either:
- Collapse into one row with a state badge:
TCP Server (10.0.0.145:4242) with a foreground only / background-ready indicator.
- Or keep two rows but label them as "Foreground connection" and "Background connection", with the second being shown only when Background Transport is on, and grouped under the same relay row.
The id distinction (tcp-tunnel vs the user's chosen entity id) is an implementation detail — the UI shouldn't surface it.
Implementation pointers
NetworkStatusViewModel builds the list of "interface" rows from AppServices.tcpInterfaces, autoInterface, etc. After the refactor it also picks up tunnelTCPInterface if exposed (verify what it currently does and adjust).- The label probably lives in
InterfaceConfig.name for the foreground entity ("TCP Server" is the default name OnboardingViewModel writes). The tunnel uses TunnelTCPInterface.makeConfig(host:port:) which hardcodes name: "TCP Tunnel" — that's what shows up.
Why deferred
The architectural commit landed without UI polish to keep the diff scoped. The Network Status page works; it's just visually confusing for users who aren't reading the diff.
Follow-up from the dual-interface refactor (
ea2e57eonfeat/enable-tunnel-flip-flag).Current behaviour
After the dual-interface change, the Network Status page lists both interfaces by their raw types. With a single user-added TCP relay + Background Transport enabled, the user sees something like:
These are one logical relay (same
host:port) being shown as two unrelated TCP clients, which doesn't communicate that the second one only exists to keep the connection alive when the app is backgrounded.What it should look like
Either:
TCP Server (10.0.0.145:4242)with aforeground only/background-readyindicator.The id distinction (
tcp-tunnelvs the user's chosen entity id) is an implementation detail — the UI shouldn't surface it.Implementation pointers
NetworkStatusViewModelbuilds the list of "interface" rows fromAppServices.tcpInterfaces,autoInterface, etc. After the refactor it also picks uptunnelTCPInterfaceif exposed (verify what it currently does and adjust).InterfaceConfig.namefor the foreground entity ("TCP Server"is the default nameOnboardingViewModelwrites). The tunnel usesTunnelTCPInterface.makeConfig(host:port:)which hardcodesname: "TCP Tunnel"— that's what shows up.Why deferred
The architectural commit landed without UI polish to keep the diff scoped. The Network Status page works; it's just visually confusing for users who aren't reading the diff.