Quick connect (#5112) in desktop UI - PR #5185 + Auto formula thoughts

Developers
1

Hey everyone,

Following #5112 (Quick connect algorithm) which landed in core and the nym-vpnc CLI on the develop branch, the Linux/Windows Tauri desktop app didn’t yet expose this feature. I’ve put together a small PR that fills that gap, plus a couple of thoughts on how the algorithm could evolve. Wanted to share here for visibility and discussion alongside the PR review.

400×809 31.1 KB

PR: nymtech/nym-vpn-client#5185

What the PR does

Core selection logic is unchanged. The PR is purely the desktop UI wiring layer:

  • A new Tauri command (set_gateway_selection_algorithm) that mirrors the CLI pattern in nym-vpnc/src/commands/tunnel.rs
  • A Quick connect toggle on the Home screen (Fast / WireGuard mode only - hidden in Anonymous / mixnet so the algorithm semantics stay clean)
  • HopSelect cards show the actually-picked gateway info once a connection starts, so users see which gateways got selected instead of a flat “Auto” placeholder
  • State hydrates from daemon config at startup and stays in sync if the user changes algorithm via CLI or config
  • Generated TS bindings checked in; the tsgen script now formats both tauri.ts and bindings.ts

Two preliminary cleanups also went in:

  • 1-line lib-types fix: use ts_rs::TS; was missing under the typescript-bindings cfg in nym-vpn-lib-types/src/gateway_selection_algorithm.rs (mirrors the pattern already in service.rs of the same crate)
  • ts-rs version bump 11.0 → 12.0.1 in nym-vpn-app/src-tauri to align with the core workspace; otherwise two ts_rs::TS trait impls collide in the graph once typescript-bindings is enabled

Tested end-to-end against an installed nightly 1.30.0-beta daemon (commit de7d981). Toggling Quick connect ON in the UI updates the daemon’s gateway_selection_algorithm_config.gateway_selection_algorithm from Explicit to Auto (verified via daemon log and config persistence on disk); a subsequent Connect succeeds with auto-selected gateways and the cards reflect the actual entry/exit names.

Where I’d value team / community input

  1. UX in Anonymous mode: Auto requires WireGuard / 2-hop. The toggle is currently hidden in Anonymous mode and the algorithm auto-resets to Explicit with a toast. Alternatives considered: (a) keep visible but disabled with tooltip, (b) clicking it auto-switches the user to Fast. Going with hide-and-toast for v1; happy to change if there’s a different preference.
  2. Toggle placement: currently between the mode selector and the Entry card. Settings could also work - Home felt like the right place for a quick-action but I’d defer to the desktop team.
  3. enable_geo_location exposure: left at backend default (true) and not surfaced in UI v1. Worth exposing now or in a follow-up?
  4. Generated bindings checkin policy: the auto-generated bindings.ts is checked in with the PR. Some projects keep generated files out of git; happy to gitignore if that’s the preference.

Two follow-up ideas (separate PRs, scoping interest welcomed)

While testing Quick connect locally I ran into one situation where the deterministic Auto pick led to repeat handshake timeouts on the same gateway pair (turned out to be a foreground-daemon-mode permission issue on Windows; the proper service-mode test connected fine). It still pointed at two improvements worth thinking about:

1. Top-N randomization within the best tier

Auto today picks the single closest non-jurisdiction gateway by Haversine distance. If that gateway is unreachable for any reason - firewall, transient outage, ISP route weirdness, gateway under unrelated load - retries deterministically pick the same gateway and keep timing out.

A small change - pick uniformly at random from the top-N closest within a small distance window (say N=5) - converts “stuck on bad pick” into “next try gets a different candidate”. No new data needed, doesn’t change the algorithm shape, fits in the existing selector.

2. Richer scoring beyond filter + Haversine

Auto today: filter (same jurisdiction) + sort (closest by Haversine).

Factors that could be added, each independent and opt-in / weighted:

  • Saturation penalty - penalize gateways in over-concentrated countries / ASNs to spread the network
  • Exit quality signals - SMTP egress clean, IPv6 default, residential vs hosting tier
  • Jurisdiction tier - avoid “extreme operator-risk” jurisdictions for entry/exit even if geographically optimal
  • Per-client recent-latency cache - fast-path pre-selection based on actually-measured RTTs to candidates
  • Entry-close-to-user / exit-far-from-entry tradeoff - as a tunable rather than fixed

Each would need either new fields in nym-api (gateway metadata) or an auxiliary curated dataset shipped with the daemon. I’ve been experimenting with similar scoring in a separate gateway-scoring tool (used today by node operators for deployment recommendations) - happy to draft a scoping issue if the core team is interested.

Why this matters

Quick connect is the kind of feature that lowers the activation cost for new users - they don’t need to know what entry/exit to pick or what jurisdictions trade off against what. CLI users are already getting this via nym-vpnc. Bringing the same thing to the desktop seems like a natural completion of #5112 for the upcoming v2026.9 (Schilthorn) release.

Open to revising the PR as the desktop and core teams see fit.

Cheers!

1 Like