Desktop

Supported platforms

The EON Path desktop client is a GUI application (Wails: Go backend, web frontend) built on the same Go core used by the mobile apps. It supports:

Install

The desktop client is built from source per platform. Each platform has a dedicated build guide with prerequisites and packaging steps:

• macOS: cmd/eonpath_client/BUILD_MACOS.md in the source repository
• Windows: cmd/eonpath_client/BUILD_WINDOWS.md in the source repository
• Linux: make build-client (see the project’s BUILDING.md)

General prerequisites are Go, Node.js/npm, and the Wails v2 CLI; see BUILDING.md for full per-platform setup instructions.

On macOS, make release produces the release artifact end to end: a universal binary, Developer ID signing with the hardened runtime and a secure timestamp, a .dmg, and notarization with the ticket stapled into it. It needs APPLE_DEVELOPER_ID, APPLE_ID, APPLE_APP_PASSWORD and APPLE_TEAM_ID in the environment.

Connection methods and privileges

The client offers two kinds of endpoint, and the difference matters on a desktop:

The client asks its own backend whether routes can actually be installed on this machine, rather than guessing from the platform name, and leaves routing endpoints out of the list when they can’t. That is not cosmetic: starting a routing endpoint without the privileges gives a tunnel that establishes, reports connected and carries nothing, because installing the routes is the part that fails.

A privilege-free path exists in principle on macOS (a NetworkExtension provider, which needs one-time user consent instead of root) and on Windows (a service installed once with administrator rights). Neither is implemented; the capability check is written so that it reports on the strength of the provider once one exists, without a platform check to update.

First connection

When you open the client for the first time, add the server you want to connect to by its address — a DNS name (for example vpn.example.com) or IP address (for example 203.0.113.10).

On the first connection to a new server, the client performs the ML-DSA-87 post-quantum key exchange and then verifies the server’s identity before establishing the tunnel. This identity check is mandatory: the client will not connect to a server whose identity it cannot verify, using either a pinned identity hash configured for that endpoint or a DNS TXT record. See Server identity pinning for how this works, and Configuration for how to set up an endpoint’s identity pin or DNS TXT record.

Once the server’s identity is verified, the client brings up a WireGuard tunnel keyed from the post-quantum exchange, and traffic is routed through it.