Void Presence Application v4.0.0
Release details for the void presence application application loaded from GitHub release data and package.json tag.
Release details for the void presence application application loaded from GitHub release data and package.json tag.
If you just need the latest stable application build, you can always download it from the main download page.
Go to download pageView this release on GitHub for full changelog and assets.
Check GitHubThe main reason for introducing the internal REST API endpoint is to move all sensitive update and upload logic off the client and into the backend. By doing this, the Electron app no longer needs to know about internal author identifiers or touch the database layer directly. Instead, it only talks to a stable HTTP surface, and the server is responsible for resolving author IDs, enforcing permissions, and shaping responses.
From a security perspective, this effectively closes off direct database exposure and reduces the blast radius of any client-side issue. The client sees opaque IDs and sanitized payloads, while the backend can evolve its schema, validation and authorization rules without leaking internals to the outside world. This also makes it easier to apply API security best practices such as “do not expose more data than necessary”, strict rate limiting and centralized error handling in one place.
This also opens the door to working with sensitive integrations entirely on the API side, including Discord tokens and other secret-bound flows. With that logic moved out of the Electron client, it becomes possible to reuse the same backend for future web or bot versions of Presence without exposing secrets in the desktop app.
The new version was already ready to ship, but 3.0.1 kept it blocked because of the weekly contract requirement. This delayed the release even though the update itself was prepared and fully functional.
This issue has worried me for a long time, because with only the database address it would be possible to expose or extract a lot of sensitive information. By sensitive data here, I also mean abuse risks such as artificially inflating activity, stats, or presence counts through author IDs and related internal fields. Again, we are not storing tokens or client IDs, but fake engagement, spammed presences, and manipulated statistics are still a real problem and something I want to prevent.
https://api.voidpresence.site/v1/github/application that proxies the latest GitHub release for the main app, returning the tag, installer asset name, download URL, and release notes body as JSON..txt file.api.voidpresence.site instead of calling GitHub directly from the client.