| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| README.md | 2026-07-27 | 1.6 kB | |
| v5.5.4 -- fix the desktop download buttons source code.tar.gz | 2026-07-27 | 29.6 MB | |
| v5.5.4 -- fix the desktop download buttons source code.zip | 2026-07-27 | 29.7 MB | |
| Totals: 3 Items | 59.3 MB | 0 | |
Fixed
The desktop download buttons still led to a dead GitHub page.
5.5.3 updated one of the two places these links live. The platforms menu on the connection screen keeps its own DOWNLOADS table, and it was missed — it stayed on 0.1.0.
The stale entries used /releases/latest/download/<file>. GitHub resolves latest by redirecting to the newest tag, so once desktop 0.3.0 shipped, a link written for 0.1.0 resolved to:
/releases/download/v0.3.0/SecureBit.Chat_0.1.0_x64-setup.exe
A file that never existed under that tag. The browser navigated to GitHub and downloaded nothing — which is why it looked like a working link that simply did nothing.
Both places now build their URLs from a single DESKTOP_VERSION constant with the release tag pinned.
Added
tests/desktop-download-links.test.mjs fails the build if this drifts again. It requires every source to derive its URLs from that constant, rejects /releases/latest/download/ and hardcoded versions in filenames, and fetches each generated URL to prove the release asset is really there.
Desktop apps
| Platform | Download |
|---|---|
| Windows 10/11 | SecureBit.Chat_0.3.0_x64-setup.exe (github.com) |
| macOS 11+ | SecureBit.Chat_0.3.0_x64.dmg (github.com) |
| Linux | SecureBit.Chat_0.3.0_amd64.AppImage (github.com) |