Repository navigation
Releases: uqrealitylabs/questrelay
Release list
QuestRelay v0.8.2
The v0.8.1 images had to be rebuilt with missing Docker build inputs supplied by a backfill job. This release carries those repairs in the Dockerfiles themselves. The Rust builder installs rustfmt, which mediasoup needs while generating code. The web builder copies the shared TypeScript config before compiling the room
The release workflow checks the web app, Rust relay, Quest app and deployment files, then publishes two GHCR images from this tag:
ghcr.io/uqrealitylabs/questrelay-backend:v0.8.2
ghcr.io/uqrealitylabs/questrelay-frontend:v0.8.2
The downloads below include a Linux x86_64 relay binary, a Quest debug APK for ADB testing and SHA-256 checksum files. The Quest package still needs a separate signed build for a normal Meta release channel
No streaming protocol or room behaviour changed. The relay remains self-hosted while Cloudflare Realtime integration is being built. The deployment guide explains the server keys, HTTPS and direct media port
QuestRelay v0.8.1
The v0.8.0 tag stopped before publishing its builds. A path-filter test read the tag environment while checking an explicit file list, then failed because every job appeared to be selected. v0.8.1 fixes that boundary and passes the full web, Rust, Quest and deployment checks
Pick the build you need
| Download | Use it for |
|---|---|
questrelay-quest-debug-v0.8.1.apk |
ADB testing on a Quest with Developer Mode. This is debug-signed and cannot stand in for a Meta release-channel build |
questrelay-linux-x86_64-v0.8.1 |
Running the Rust relay on a compatible Linux x86_64 host after setting the required keys and media address |
.sha256 files |
Checking the downloads before installing them |
Versioned containers are published at ghcr.io/uqrealitylabs/questrelay-backend:v0.8.1 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.8.1. The tagged Dockerfiles missed two build inputs, so the image backfill supplies rustfmt and the root TypeScript config while keeping the application code at this tag. The repository is private, so pulling those images requires package access. The deployment guide covers HTTPS, keys, the media port and backups
This release still uses the self-hosted relay. Cloudflare Realtime is being integrated separately. One Quest has sent video and an Opus track to a local browser. Audible game audio, several headsets at once and internet latency still need measured tests
QuestRelay v0.8.0
QuestRelay’s version numbers lined up across the Rust relay, web workspaces and Quest app for the first time. The release workflow also gained two container targets: a backend image for the media service and a frontend image for the viewing room
The browser and Quest still use the self-hosted mediasoup relay in this version. The Quest app can send H.264 video and an Opus audio track after the wearer approves screen capture, while the web room can subscribe to selected feeds. The admin view handles rooms, access and headset controls
What happened to the original build
The tag run passed the component checks but stopped in a test of CI’s path selection. The test supplied an explicit file list while inheriting the tag environment, causing the selector to mark every component changed. That failure prevented the container publish and release packaging jobs from running. The fix is in v0.8.1
The image backfill packages this tag's application code at ghcr.io/uqrealitylabs/questrelay-backend:v0.8.0 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.8.0. The release assets contain a Linux x86_64 relay binary, Quest ADB test APK and checksums. The APK is debug-signed and is not a Meta release-channel package
QuestRelay v0.7.0
The media path did not change in this release. The work was about making the project easier to find, build and ship without touching unrelated parts of the stack
- Documentation moved under
docs/, with the architecture and deployment routes written down in one place - Deployment configuration moved under
tools/config/, and scripts moved undertools/scripts/ - CI began checking only the affected web, Rust, Quest or deployment code, and reusing dependency caches where it helps
The release assets include a Quest ADB build, Linux x86_64 relay binary and checksums. The containers are ghcr.io/uqrealitylabs/questrelay-backend:v0.7.0 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.7.0. For the current setup and known media limits, use the README
QuestRelay v0.6.0
The Quest companion app became part of the media path. After the wearer approves Android's capture prompts, it encodes the display as H.264 and eligible game playback as Opus, then sends both tracks to the Rust relay. The app has separate Live, Settings and Stats screens, a relay connection check, auto/manual quality controls and packet, queue and reconnect diagnostics
This version also introduced release and deployment scripts, the first CI and security workflows, Dependabot updates and the project policies. The Docker images contain the Rust service and web frontend. The Quest APK is a debug-signed ADB test build, not a store-signed install
The release assets contain the Quest APK, Linux x86_64 relay binary and checksums. The matching containers are ghcr.io/uqrealitylabs/questrelay-backend:v0.6.0 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.6.0
Note
Android can only capture playback that the game and platform permit. A visible audio packet counter is not proof that a specific title's sound is audible or in sync
QuestRelay v0.5.0
Mochi stopped being a static badge. The capybara was redrawn and given 22 reactions, from blinks and a quiet wave to a boop, a dance or a startled look when the room hits an error
Mochi follows the pointer with its eyes, winks on hover or keyboard focus, and changes its idle behaviour for waiting, connecting, live, muted, offline and error states. Admins can set a mood and accessory for a room, so the character can feel different on each stream
The motion pauses in a hidden tab, cleans up its listeners and timers, and honours reduced-motion preferences. The animation styles and interaction tests live with the capybara component rather than being scattered across the room
The v0.5.0 backend and frontend images are on GHCR at ghcr.io/uqrealitylabs/questrelay-backend:v0.5.0 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.5.0. A Linux x86_64 relay binary and checksum are attached below. The installable Quest app arrived in v0.6.0
QuestRelay v0.4.0
This is the first version with a distinct experience for the person watching and the person running the room
| Viewers | Operators |
|---|---|
| Join a public room or enter its access code, then choose which live feeds to watch | Sign in before opening /admin, then manage rooms, access and headset media controls |
| Pin a feed, change layout, mute playback and keep theme preferences locally | Read relay health, headset packet and bitrate counters, recent uptime and connection guidance |
The browser now creates receive transports only for the feeds a viewer selects. The server gained passkey sign-in and admin account management, and Docker/Compose files appeared for a self-hosted Linux setup
The Dockerfiles begin with this tag. Their web build still referred to an archived prototype workspace whose manifest had dropped out of the tree. The historical image build restores that manifest from the tag's own lockfile and supplies missing build tools without changing the viewer or relay code
The release assets include a Linux x86_64 relay binary and its SHA-256 checksum. The two container tags are ghcr.io/uqrealitylabs/questrelay-backend:v0.4.0 and ghcr.io/uqrealitylabs/questrelay-frontend:v0.4.0. There is no Quest APK yet
QuestRelay v0.3.0
The headset side and the viewing room first met at the Rust API in this version. A publisher can send H.264 and Opus RTP packets over an authenticated WebSocket. The relay hands the tracks to mediasoup for WebRTC viewers
Room access stopped being a single shared viewer key. The API exposes room information and issues short-lived, single-use tickets after checking a public room or its private access code. Admin sign-in and room settings live on separate endpoints, with access attempts limited and persisted settings loaded on restart
The repository layout also moved towards frontend/, backend/ and the Quest work area. The full companion app UI and installable APK arrived later
QuestRelay v0.2.0
QuestRelay gained a Rust media service here. The new Axum WebSocket endpoint handles signalling while mediasoup creates the WebRTC transports that browsers use to receive video and audio
The relay keeps publishers and viewers separate, tracks each headset's producers, and closes consumers and transports when a peer leaves. Configuration checks reject missing keys or an unusable announced media address before the service starts. Tests exercise joining, publishing, subscribing and cleanup
The earlier web room was still being connected to this service, and a Quest did not yet have an ingest path. This release is the transport foundation for the versions that follow
QuestRelay v0.1.0
The first QuestRelay room was a place to work out how watching several headsets should feel in a browser. The web app moved into frontend/, and the audience page gained a headset lounge, a main viewing area and controls that made sense even with several tiles on screen
In the room
- Choose which headset to watch, focus one feed or start watching every available feed
- Adjust theme, density and accent in the room settings, with preferences saved in that browser
- See a useful empty state and automatic retry message when the headset list cannot load
This version was about the viewing interaction. It predates the Rust relay and the Quest capture app, so there was no headset-to-browser media path to package as a container yet