One catalog entry per server, tunnel as a connect-time choice #208

New issue

Open

opened 2026-08-29 13:14:05 -04:00 by mysticalsoap · 1 comment

mysticalsoap commented

2026-08-29 13:14:05 -04:00

Owner

The ProtonVPN WireGuard import (#196) followed the inherited Mullvad pattern: a separate -WireGuard sibling entry per server. For Mullvad that pattern was honest - its OpenVPN and WireGuard relays were different hosts. For Proton both tunnels ride the same EntryIP, so the catalog now lists the same physical server twice, identical in everything but tunnel, public_key and port.

This is the trajectory of the whole catalog, not a Proton quirk: every supported provider is WireGuard-capable server-side (AirVPN #209, Windscribe #210), and importing each the sibling way doubles its slice of the server list.

End-state: one entry per server carrying both tunnels' data, with the tunnel chosen at connect time. The natural home for that choice already exists - the per-provider protocol selection, where WireGuard 51820 becomes another row next to UDP 1194 / TCP 443.

Seams it touches: the entry tunnel field currently drives the server-tab protocol filter, profile matching, catalog.connect_dict, and the dispatch in tunnel.work() - a unified entry needs a capability representation ("supports both") plus the selection plumbed through gui, cli and profiles.

Sequencing: after #176, which rebuilds the same tunnel-selection seams - doing this first would mean reshaping them twice. Related: #52 (server metadata overhaul - same data model), #153 (list navigation - sibling doubling makes it worse).

The ProtonVPN WireGuard import (#196) followed the inherited Mullvad pattern: a separate `-WireGuard` sibling entry per server. For Mullvad that pattern was honest - its OpenVPN and WireGuard relays were different hosts. For Proton both tunnels ride the same EntryIP, so the catalog now lists the same physical server twice, identical in everything but `tunnel`, `public_key` and port. This is the trajectory of the whole catalog, not a Proton quirk: every supported provider is WireGuard-capable server-side (AirVPN #209, Windscribe #210), and importing each the sibling way doubles its slice of the server list. **End-state**: one entry per server carrying both tunnels' data, with the tunnel chosen at connect time. The natural home for that choice already exists - the per-provider protocol selection, where WireGuard 51820 becomes another row next to UDP 1194 / TCP 443. **Seams it touches**: the entry `tunnel` field currently drives the server-tab protocol filter, profile matching, catalog.connect_dict, and the dispatch in tunnel.work() - a unified entry needs a capability representation ("supports both") plus the selection plumbed through gui, cli and profiles. **Sequencing**: after #176, which rebuilds the same tunnel-selection seams - doing this first would mean reshaping them twice. Related: #52 (server metadata overhaul - same data model), #153 (list navigation - sibling doubling makes it worse).

mysticalsoap added the

architecture

label

2026-08-29 13:14:05 -04:00

mysticalsoap referenced this issue

2026-08-29 13:14:14 -04:00

AirVPN WireGuard import #209

mysticalsoap referenced this issue

2026-08-29 13:14:21 -04:00

Windscribe WireGuard import #210

mysticalsoap referenced this issue

2026-08-29 13:14:28 -04:00

Explore WireGuard support for double-hop #176

mysticalsoap commented

2026-08-29 14:16:46 -04:00

Author

Owner

Boundary with #52 settled: the two are one disease (structured data encoded into display strings - here, tunnel capability encoded as a name suffix plus a duplicated row). Division of labor:

#52 owns the target schema, including the tunnel capability field: one entry per server, tunnel(s) as structured data, siblings collapsed during its alpha-2 rekeying (entry keys get rebuilt there anyway, and the no-migration rule means each schema change costs one round of entry-point handling - two reshapes would pay it twice).
This issue narrows to the connect-time selection mechanics on top of that schema: the tunnel choice as a per-provider protocol row, plumbed through connect_dict, tunnel.work() dispatch, profiles, gui and cli. Still sequenced after #176, which reworks the same seams.

#209/#210 then target the #52 schema, not sibling entries.

Boundary with #52 settled: the two are one disease (structured data encoded into display strings - here, tunnel capability encoded as a name suffix plus a duplicated row). Division of labor: - **#52 owns the target schema**, including the tunnel capability field: one entry per server, tunnel(s) as structured data, siblings collapsed during its alpha-2 rekeying (entry keys get rebuilt there anyway, and the no-migration rule means each schema change costs one round of entry-point handling - two reshapes would pay it twice). - **This issue narrows to the connect-time selection mechanics** on top of that schema: the tunnel choice as a per-provider protocol row, plumbed through connect_dict, tunnel.work() dispatch, profiles, gui and cli. Still sequenced after #176, which reworks the same seams. #209/#210 then target the #52 schema, not sibling entries.

mysticalsoap referenced this issue

2026-08-29 14:16:56 -04:00

Overhaul server metadata (country system, tiers, features) #52