# AetherGUI: ships as Aethon, bundles someone else's core, and keeps Psiphon's fetch script

> A Tauri v2 client that wraps the CluvexStudio Aether networking core and the Xray routing engine into a Windows and Android VPN app. The interesting decisions are all in the edges: a package id frozen at the old product name, four PowerShell fetch scripts for a cross platform framework, one test file with no test runner, and a suspended feature whose build script still ships.

**hamvex/AetherGUI** — Independent production-ready Windows GUI for Aether — Tauri v2 and Rust

- Repository: https://github.com/hamvex/AetherGUI
- Stars: 332 · Forks: 44
- Language: Rust
- License: AGPL-3.0
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/hamvex-aethergui

## Three names for one client and a package id frozen at the old one

The repository is `hamvex/AetherGUI`. The product heading is `Aethon`. The manifest is `@hamvex/aether-gui`. And the Android application id is `io.github.hamvex.aethergui`, which the README says is retained for update compatibility.

That last one is the interesting decision. The Android package id is the identity an operating system uses to recognise an application as an upgrade of a previous one. Holding it at the old name means existing installs keep updating, and it also means the rename to Aethon can never be applied to Android without becoming a different application in the store.

So four identifiers, three of which are historical. Only the heading is current.

The client is explicitly not the core. It is described as an independent Windows and Android client for the official CluvexStudio/Aether networking core, and version 2.1.1 bundles the verified Aether 1.9.0 core together with the Xray 26.3.27 routing engine. Two upstreams, one of them a networking core and the other a routing engine, neither of them in this repository.

The repository root reflects that layering: `NOTICE.md`, `TRADEMARK.md`, a `third-party/` directory, and a software bill of materials in two formats, `AETHON_SBOM.json` and `AETHON_SBOM.md`. Shipping a bill of materials in both a machine readable and a human readable form is unusual and useful, and it is what you would expect from a project whose licence is AGPL-3.0 and whose payload is someone else's binary.

## A patch release and a major release 33 minutes apart

Three releases are listed. `v1.2.1` on 2026-08-18 at 23:04, `v2.0.0` on 2026-08-19 at 00:38, and `v2.1.1` on 2026-09-13 at 20:46.

The first two are thirty three minutes apart and cross a major version boundary. A patch release immediately followed by a major release an hour later is either a mislabelled tag or a planned cutover executed in the wrong order, and the release notes for 2.1.1 do not mention it.

The third is nearly a month later and the last push is at 21:27 on the same day, about forty minutes after the tag. So the branch was still moving after the release was cut, which is the ordinary pattern and also means the tag is not the head of the branch.

The release notes themselves are organised under three headings, Windows routing and settings, Android parity interface, and application updates, with a fourth section for versions and compatibility. The Windows section is the most substantive: transactional single session routing helper and Xray lifecycle management, recovery for stale Aethon owned TUN adapters and failed routing sessions, preserved sanitised Xray exit diagnostics with immediate reconnect cleanup, and restored Scan Mode with protocol specific MASQUE transport controls.

That last item is worded carefully. Scan Mode was restored, and obsolete MASQUE obfuscation values were migrated without confusing them with Scan Mode. Two features that share a word in common, kept deliberately distinct.

## Psiphon is suspended and its fetch script still ships

The Psiphon section is the most precisely hedged paragraph in the file. The Windows Psiphon second hop integration is described as experimental and suspended, and as not included in the current release. It is awaiting official Psiphon integration guidance and valid `SponsorId` and `PropagationChannelId` configuration. Psiphon is not exposed in the interface, is not launched by the production backend, and its executable is not bundled in current installers.

What is kept is the completed implementation, the pinned source revision, reproducible build instructions, the licence, and the provenance. And the file closes with a sentence that is worth repeating: no Psiphon traffic success is claimed.

Against all of that, the manifest defines a fourth fetch script alongside the ones for the core, the routing engine and the Android assets:

```json
    "fetch:psiphon":  "powershell -NoProfile -ExecutionPolicy Bypass -File scripts/fetch-psiphon.ps1"
```

The README does add that this command is for developers building from source and is not needed by normal builds or by release packaging. So the script existing is not a contradiction of the suspension, but it does mean the suspension is enforced by convention and by packaging discipline rather than by anything in the build.

Three separate reasons are given for suspending it, and they are worth keeping apart: missing vendor guidance, missing configuration values, and an explicit refusal to claim the feature works. The third is the one that makes this a well documented gap rather than a bug.

## Every build and fetch script is PowerShell with execution policy bypass

Six scripts in the manifest, five of which invoke PowerShell directly. There is one for fetching the Aether core, one for Xray, one for Psiphon, one for the Android assets, and one that packages the release. Every one of them is spelled the same way, with `-NoProfile` and `-ExecutionPolicy Bypass`.

Bypassing the execution policy is the standard way to run a vendored script on a machine whose policy forbids it, and it is defensible for a project whose build runs on a developer workstation. It does mean the repository will not build on Linux or macOS, because there is no shell equivalent for any of the five.

The Android path doubles down on it. The build script changes directory and runs `gradlew.bat`, the Windows batch wrapper, rather than the POSIX `gradlew`. There is a `package-lock.json` at the root and a single dev dependency, the Tauri command line interface, so the JavaScript side is not the constraint; the five PowerShell entry points are.

That is a coherent choice for a Windows first client with an Android companion, and it is worth being explicit about because Tauri v2 is routinely used to target macOS and Linux from the same codebase, and this repository does not.

## One test file, one dev dependency, no test runner

The test script is a single invocation of a single file:

```json
    "test":  "node tests/frontend.test.mjs"
```

There is no test framework in the dependency list. The only dev dependency is the Tauri command line interface, and the runtime dependencies are the Tauri API and an opener plugin. So the suite runs on Node's built-in facilities or is hand written, and a Rust project with a `src-tauri/` directory, an `android/` directory and a `tests/` directory at the root wires no `cargo test` into any script.

That is a thin test surface for a codebase that manages TUN adapters, routes a VPN, spawns a routing engine lifecycle, and verifies downloaded binaries. It is also consistent with the rest of the repository, which documents its own boundaries precisely and its verification thinly.

The one place verification is described in real detail is the update path, and it is worth reading next to the test story because the contrast is the point. Checksums, signing certificates and update URL restrictions are all specified; unit coverage is one script name.

## The update channel is the latest endpoint and the release assets are a contract

Both clients poll one URL:

```text
https://api.github.com/repos/hamvex/AetherGUI/releases/latest
```

The latest endpoint rather than a versioned one, so a running installation always sees the newest tag the moment it exists. What keeps that safe is not the URL but the asset naming convention the project imposes on itself, listed as requirements for future releases.

A Windows installer must be named with the version in it. An Android universal package must be named with the version in it. SHA-256 digests must be supplied either by GitHub or in a checksum asset. Release notes must live in the release body. Android packages must be signed with the same established signing key.

That is a release interface rather than a naming convention, and the auto updater depends on it. If a future release drops the universal package or renames the installer, the updater has nothing to fetch.

Two platform specific details follow from it. Automatic checks run at startup and every twelve hours while the application is open, with manual controls added to both settings pages, current version, latest version, update status and the release notes all shown in the app, and an option to download automatically. Android downloads over Wi-Fi using the platform download manager for resumable transfers and verifies that the downloaded package carries the same signing certificate as the installed application. Windows downloads the official x64 setup executable and reports progress in the app.

So the content is verified on both platforms by SHA-256, and the identity is verified on Android by certificate. Windows has no signature to compare, which is the same reason it triggers a SmartScreen warning.

## Android lost its language selector in the release where Windows gained Persian

Two bullets of the 2.1.1 notes sit next to each other under a heading called Android parity interface, and read as opposites.

The first says English and Persian application translations were added, with right to left layout support. The second says Android locale overrides, Persian resources, right to left support and the language selector were removed. The third says a Windows language selector was added and VPN features and routing behaviour were preserved.

Read together, this is a migration rather than a reversal. Android had Persian resources and a language selector; those came out. Windows gained Persian and gained a selector. The net result is a Windows client with two languages and right to left layout, and an Android client with no language selector, which is a plausible trade if the Android translations had drifted.

The heading calls the goal parity, and the release does deliver one thing parity did not require: a Windows language selector.

Android versioning is where the two platforms are hand synchronised. The Windows version, the Android version name and the release tag all read 2.1.1, while the Android version code is 23. A version code is a separate monotonic integer that the store uses for ordering, so every release has to bump both and keep them consistent, and the README lists the code alongside the name so a reader can check which build is installed.

One more identifier is fixed for compatibility. The Android application id stays at `io.github.hamvex.aethergui`, so a rename of the product can never reach the Android package identity.

## Ten release assets, four mode concepts and one fixed SOCKS5 port

The download list has ten assets for one release. There is a combined archive holding the Windows and Android builds, a Windows setup executable, an MSI, a portable Windows zip, four Android packages split by architecture plus a universal one, an Android App Bundle, and a checksum file. The universal package is described as carrying ARMv7, ARM64 and x86_64 libraries.

Four mode concepts sit in a five step quick start. VPN Mode gives system wide routing and may request administrator permission when configuring the TUN adapter and protected routes. Manual SOCKS5 gives proxy only use and its listener defaults to `127.0.0.1:1819`, a fixed non standard port. Scan Mode was restored in this release. And protocol specific MASQUE transport controls choose HTTP/3 or HTTP/2.

A fifth is named in the closing line of the release notes, where existing VPN services, state management, routing recovery, Smart Connect and split tunneling are said to remain in place. Those five subsystems are named and not described anywhere in the visible documentation.

Diagnostics is the sixth surface, offering live logs, connection testing and network recovery from inside the application, which is the only way to read the routing engine logs without a shell on a machine whose routing you have just changed.

And one policy note is worth surfacing. If the Android package is distributed through Google Play, the use of the install packages permission and direct self updates should be reviewed against current Play policy. The project is documenting a risk to its own update design.

## Conclusion

Aethon is a reasonable choice if you want a Windows client for the Aether core that somebody else maintains, since the bundling, update channel and checksum contract are documented precisely. Two things to weigh first. The Windows installer is unsigned and will trip SmartScreen, and every build script in the repository is PowerShell, so the project cannot be built from Linux or macOS even though Tauri can. If you rely on Psiphon as a second hop, note that it is not in this release at all.

## FAQ

### What is AetherGUI, and what does it bundle?

It ships as Aethon, an independent Windows and Android client for the CluvexStudio/Aether networking core. Windows version 2.1.1 bundles the verified Aether 1.9.0 core together with the Xray 26.3.27 routing engine, offering system wide VPN routing or a local SOCKS5 proxy. The manifest is `@hamvex/aether-gui` and the Android id is `io.github.hamvex.aethergui`.

### Does AetherGUI support Psiphon?

Not in the current release. The Windows Psiphon second hop integration is described as experimental and suspended, is not exposed in the interface, is not launched by the production backend, and its executable is not bundled in current installers. A `fetch:psiphon` script exists for developer source builds, and no Psiphon traffic success is claimed.

### How do AetherGUI updates work?

Both clients poll the GitHub latest release endpoint for the repository. Checks run at startup and every twelve hours. Windows downloads the official x64 setup installer and Android uses the platform download manager over Wi-Fi. Both verify SHA-256, Android also compares signing certificates, and update URLs are restricted to the official repository.

### Why does the AetherGUI Windows installer trigger a SmartScreen warning?

The release notes state that Windows binaries are currently unsigned. Android release packages are signed with the established Aethon signing certificate, and the Android updater additionally verifies that a downloaded package uses the same certificate as the installed application, so the two platforms have different trust postures.

### Can I build AetherGUI on Linux or macOS?

Not with the scripts in the repository. All five fetch and packaging scripts invoke PowerShell with `-NoProfile` and `-ExecutionPolicy Bypass`, and the Android build runs `gradlew.bat`, the Windows batch wrapper. The stated prerequisites begin with Windows 10 or 11 x64.

## Sources

- [hamvex/AetherGUI on GitHub](https://github.com/hamvex/AetherGUI)
- [Issues](https://github.com/hamvex/AetherGUI/issues)
- [License: AGPL-3.0](https://github.com/hamvex/AetherGUI/blob/main/LICENSE)
- [README](https://github.com/hamvex/AetherGUI/blob/main/README.md)
- [Releases](https://github.com/hamvex/AetherGUI/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hamvex-aethergui