Guides
Full documentation and how‑tos for the Netplay Hub
Documentation
Version 1.3
o==========================================================o
| Remz Netplay Hub - Documentation v1.3 |
o==========================================================o
| |
| Updates : https://remz.ca/lobby/documentation.html |
| |
o==========================================================o
Changelog
---------
v1.3 (Dec 2025)
- Added Discord Bot Integration (remz_bot.py) for Waiting Games alerts.
- Updated Table of Contents and Conclusion.
- Added bot commands and paths to Appendices.
v1.2 (Nov 2025)
- Added support for relay servers (RetroArch 1.21.0 syntax with --mitm-session).
- Implemented password-protected lobbies via temporary config injection (--appendconfig).
- Restored admin login compatibility with ADMIN_PASSWORD environment variable.
- Updated launcher to handle new URI parameters (relay, password, session).
- Improved logging in launcher for reproducibility and troubleshooting.
v1.1
- Minor fixes to admin mode and backend session handling.
- Documentation refinements and validation checklist updates.
v1.0 (initial release)
- Complete workflow: backend, front end, listener, launcher, RetroArch.
- Admin mode introduced with password authentication.
I. Introduction
---------------
This document describes the complete, working setup for browsing RetroArch
lobbies and joining games with a single click. It covers every component in
the chain — front end, backend, listener, launcher, and now Discord Bot —
along with networking and operational details. The goal is clarity,
reproducibility, and trust.
II. Table of contents
---------------------
1. Overview and data flow
2. Front end (HTML lobby browser)
2.1 Hosting and environment
2.2 UI behavior and join flow
2.3 Functions and link format
2.4 Validation checklist
3. Backend (VPS: app.py + lobbies.json)
3.1 Domain, DNS, and routing
3.2 Virtual environment and process control
3.3 API endpoints and data schema
3.4 Validation checklist
4. Listener (remz-listener.exe)
4.1 Port, endpoints, and CORS
4.2 Tray UI and logs
4.3 Build commands and binaries
4.4 Validation checklist
5. Launcher (retroarch-launcher.exe)
5.1 URI parsing and config file
5.2 Core and game resolution
5.3 Command construction and process start
5.4 Validation checklist
6. Networking and DNS (retroarch.remz.ca)
6.1 Cloudflare A record
6.2 Local loopback and ports
6.3 Security considerations
7. Operations
7.1 Build, deploy, and restart procedures
7.2 Logs and troubleshooting
7.3 Common failure modes and quick fixes
8. Appendices
8.1 Exact file paths and names
8.2 Copy-paste code snippets
8.3 Reference commands and one-liners
8.4 Discord Bot quick reference
9. Discord Bot Integration (remz_bot.py)
9.1 Purpose and behavior
9.2 Requirements
9.3 Setup: creating and inviting the bot
9.4 Running the bot
9.5 Configuring alerts
9.6 Operations, logging, and security
9.7 Validation checklist
9.8 Summary
10. Conclusion
-=-=-=-=-=-=-=-=-=-=-=-=-
1. Overview and data flow
=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose
-------
The system provides a complete workflow for browsing and creating RetroArch
lobbies, then joining games with one click. It connects a hosted front end,
a VPS backend, a local listener, and a launcher into a single chain. Each
part has a clear role and communicates with the next.
Components
----------
- Backend (VPS: app.py + lobbies.json)
* Runs on a virtual private server.
* Maintains the master list of lobbies in lobbies.json.
* app.py serves this data through an API.
* Domain retroarch.remz.ca points to the VPS via Cloudflare A record.
- Front end (HTML lobby browser)
* Hosted on a web service, accessible via browser.
* Fetches lobby list from the backend and displays it.
* Allows users to create new lobbies, which are sent to the backend and
then appear on the page.
* Provides "Join Game" buttons that send join requests to the local listener.
- Listener (remz-listener.exe)
* Runs locally on the user’s machine.
* Listens on http://localhost:8080.
* Receives join requests from the front end.
* Calls the launcher with a remz://join?... URI.
- Launcher (retroarch-launcher.exe)
* Parses the URI passed by the listener.
* Reads launcher-config.json for paths.
* Resolves core and game files.
* Builds RetroArch command line and starts RetroArch.
- RetroArch
* Loads the specified core and game.
* Connects to host for netplay or starts a local game.
Data flow
---------
1. Backend creates and serves lobbies (via app.py and lobbies.json).
2. Front end fetches lobbies from backend and displays them.
3. User may create a new lobby → backend updates lobbies.json → front end
shows the new lobby.
4. User clicks "Join Game" → front end sends GET /join?... to localhost:8080.
5. Listener receives request → calls launcher with remz://join?... URI.
6. Launcher parses URI, finds core and game, builds command.
7. Launcher starts RetroArch with proper arguments.
8. RetroArch connects to host or starts local game.
Validation
----------
- Backend responds with lobby list at retroarch.remz.ca.
- Front end shows lobbies and allows creation.
- Each click produces one join request in listener logs.
- Listener log shows URI and launcher invocation.
- Launcher log shows config, resolved paths, and RetroArch command.
- RetroArch starts with expected core, game, and netplay parameters.
Summary
-------
The workflow is linear and traceable:
Backend → Front end → Listener → Launcher → RetroArch.
Each part has a single responsibility, and logs confirm the chain.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
2. Front end (HTML lobby browser)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose
-------
The front end is the user-facing component. It provides a web interface
to browse existing lobbies, create new ones, and join games. It is hosted
on a web service and communicates directly with the backend for lobby data
and with the local listener for join requests.
Hosting and environment
-----------------------
- Static HTML/JavaScript application.
- Served from a web service accessible via browser.
- Fetches lobby data from the backend domain (retroarch.remz.ca).
- Requires no local installation; runs entirely in the browser.
UI behavior and join flow
-------------------------
- Displays a list of lobbies retrieved from the backend.
- Each lobby entry shows host, port, core, game, and nickname.
- Provides a "Join Game" button for each lobby.
* Clicking the button sends a GET request to the local listener:
http://localhost:8080/join?host=...&port=...&core=...&game=...
- Provides a "Create Lobby" form.
* User enters details (core, game, nickname, etc.).
* Form submission sends data to the backend.
* Backend updates lobbies.json, and the new lobby appears in the list.
- Provides "Set Admin Mode" button.
* Clicking triggers OPTIONS then POST /admin/login.
* On success, displays "Admin mode activated."
* Admin Mode allows submitting and managing lobbies.
Functions and link format
-------------------------
- generateJoinLink(lobby):
* Builds the join URL for the listener.
* Example:
https://localhost:8080/join?host=127.0.0.1&port=55435&core=snes9x&game=Uniracers%20(U)%20[!].smc
- tryJoin(lobby):
* Executes the join request.
* Uses fetch() or XMLHttpRequest to call the listener.
* Alerts user on success or failure.
Validation checklist
--------------------
- Lobby list loads from backend domain retroarch.remz.ca.
- Creating a lobby updates backend and shows new entry in front end.
- Clicking "Join Game" produces one GET /join?... request in listener logs.
- Listener log confirms URI received.
- Launcher log confirms RetroArch command built and executed.
- Clicking "Set Admin Mode" with correct password activates admin session.
- Admin-only buttons (e.g., Submit Lobby) become available.
Summary
-------
The front end is both a browser and a controller:
- It displays lobbies from the backend.
- It allows users to create new lobbies.
- It sends join requests to the local listener.
This makes it the central user interface for the entire workflow.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
3. Backend (VPS: app.py + lobbies.json)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose
-------
The backend is the authoritative source of lobby information. It runs on
a virtual private server (VPS) and provides the data that the front end
displays. It also accepts new lobby creations from users and updates the
master lobby list. This ensures that all players see the same, consistent
set of lobbies.
Domain, DNS, and routing
------------------------
- Domain: retroarch.remz.ca
- DNS: Cloudflare A record points retroarch.remz.ca to the VPS IP address.
- Routing: All requests to retroarch.remz.ca are directed to the VPS where
app.py is running.
Virtual environment and process control
---------------------------------------
- app.py runs inside a Python virtual environment for dependency isolation.
- Environment activation:
* Linux: `source venv/bin/activate`
* Windows: `venv\Scripts\activate`
- Process control:
* app.py is started manually or via a process manager (e.g., systemd, screen).
* lobbies.json must be present in the same directory as app.py.
API endpoints and data schema
-----------------------------
- GET /lobbies
* Returns the current list of lobbies in JSON format.
* Each lobby entry includes:
- host: IP or domain of the host
- port: netplay port (default 55435)
- core: emulator core name (e.g., snes9x)
- game: filename of the ROM (e.g., Super Mario World (U) [!].smc)
- nickname: player nickname
- id: unique identifier for the lobby
- POST /create
* Accepts new lobby data from the front end.
* Updates lobbies.json with the new entry.
* Ensures the lobby appears in subsequent GET /lobbies responses.
3.5 Admin Mode
--------------
- POST /admin/login
* Accepts administrator password.
* Returns a session token if valid.
* Token is required for admin-only actions (e.g., submit or manage lobbies).
- Session management:
* Tokens are stored in memory (ADMIN_SESSIONS).
* Each token is valid until backend restart.
- Environment variable:
* ADMIN_PASSWORD must be set before starting app.py.
Validation checklist
--------------------
- Accessing https://retroarch.remz.ca/lobbies returns valid JSON.
- JSON includes expected fields (host, port, core, game, nickname, id).
- Creating a lobby via front end results in a new entry in lobbies.json.
- Front end refresh shows the new lobby immediately.
- VPS logs confirm app.py received and processed the request.
- Accessing https://retroarch.remz.ca/admin/login with OPTIONS returns 204 and CORS headers.
- POST /admin/login with correct password returns a valid token.
- Front end shows "Admin mode activated" after successful login.
Summary
-------
The backend is the foundation of the system:
- It stores and serves lobbies.
- It accepts new lobby creations.
- It ensures consistency across all users.
Without the backend, the front end would have no data to display and
joining games would not be possible.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
4. Listener (remz-listener.exe)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose
-------
The listener is the local bridge between the web front end and the launcher.
It runs on the user’s machine and listens for join requests from the browser.
Its job is to translate a simple HTTP request into a launcher invocation.
Port, endpoints, and CORS
-------------------------
- Port: 8080 (localhost only).
- Endpoints:
* GET /ping
- Returns "pong".
- Used to verify that the listener is running.
* GET /join?host=...&port=...&core=...&game=...
- Logs the request.
- Calls the launcher with a remz://join?... URI.
- CORS headers:
* Access-Control-Allow-Origin: *
* Access-Control-Allow-Methods: GET, POST, OPTIONS
* Access-Control-Allow-Headers: Content-Type
- These headers ensure that the front end (hosted remotely) can call the
listener running locally without browser restrictions.
Tray UI and logs
----------------
- Tray icon:
* Provides a small interface to view logs and exit the listener.
- Logs:
* Each request is logged with a timestamp.
* Shows the URI passed to the launcher.
* Confirms when the launcher is started.
Build commands and binaries
---------------------------
- Source code is compiled into remz-listener.exe.
- Build steps (Windows, using Visual Studio tools):
* `rc remzlistener.rc`
* `cl /EHsc remz-listener.cpp remzlistener.res /link user32.lib shell32.lib`
- Resulting binary: remz-listener.exe
- Runs as a background process with tray icon.
Validation checklist
--------------------
- Start listener → tray icon appears.
- Access http://localhost:8080/ping → returns "pong".
- Click "Join Game" in front end → listener log shows one GET /join?... request.
- Listener log shows URI and confirms launcher started.
- No duplicate requests unless user clicks multiple times.
Summary
-------
The listener is the local gateway:
- It listens on localhost:8080.
- It accepts join requests from the front end.
- It calls the launcher with the proper URI.
This ensures that remote lobby browsing can trigger local RetroArch launches
securely and reliably.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
5. Launcher (retroarch-launcher.exe)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Purpose
-------
The launcher is the local component responsible for starting RetroArch
with the correct arguments. It receives a URI from the listener, parses
it, resolves the required core and game, and builds a command line to
launch RetroArch. It ensures that the join process is seamless and
consistent.
URI parsing and config file
---------------------------
- Input: remz://join?... URI passed by the listener.
- Parses query parameters:
* host: IP or domain of the host.
* port: netplay port (default 55435 if not specified).
* core: emulator core name (e.g., snes9x).
* game: filename of the ROM.
* relay: optional flag for relay usage.
* session: optional relay session ID (used with --mitm-session).
* password: optional netplay password.
* nickname: player nickname (default "Player").
- Reads configuration from launcher-config.json:
* retroarchPath: path to retroarch.exe.
* coresPath: path to cores directory.
* gamesPath: path to games directory.
- Config file is located in the same directory as the launcher.
Core and game resolution
------------------------
- Core resolution:
* Builds path: coresPath/coreName_libretro.dll.
* Verifies that the DLL exists.
- Game resolution:
* Searches recursively under gamesPath.
* Matches exact filename provided in the URI.
* Verifies that the game file exists.
Command construction and process start
--------------------------------------
- Builds a single command line for RetroArch:
* "retroarch.exe" --connect host --port port --libretro "core.dll" "gamefile" --nick nickname
* Adds password support by writing a temporary config file containing: netplay_password = "yourpassword"
* Adds --mitm-session if relay/session parameters are present.
* Inject a password via --appendconfig if the session is password-protected.
- Uses CreateProcessW to start RetroArch.
- Working directory is set to RetroArch’s folder.
- Logs:
* Shows full command line.
* Confirms success or failure with GetLastError code if launch fails.
* Logs creation of the temporary password config file
Validation checklist
--------------------
- Listener log shows URI passed to launcher.
- Launcher log shows config path and contents.
- Launcher log shows resolved core and game paths.
- Launcher log shows full RetroArch command line.
- RetroArch starts with expected arguments, including relay and password when provided.
- Temporary password config overwrites itself each run, ensuring reproducibility without clutter.
Summary
-------
The launcher is the execution engine:
- It translates a URI into a RetroArch command.
- It validates core and game files.
- It supports relay servers (--mitm-session) and password‑protected lobbies via config injection.
- It starts RetroArch with netplay parameters.
This ensures that the join process is reliable, traceable, and compatible with RetroArch 1.21.0.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
6. Networking and DNS (retroarch.remz.ca)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose
-------
Networking and DNS ensure that the backend is reachable from anywhere
and that the front end can reliably fetch lobby data. This layer ties
the VPS to a public domain and manages how requests are routed.
Cloudflare A record
-------------------
- Domain: retroarch.remz.ca
- DNS provider: Cloudflare
- Configuration:
* An A record points retroarch.remz.ca to the VPS public IP address.
* Optional proxy/CDN features can be enabled or disabled depending on
performance and security needs.
- Result: Any request to retroarch.remz.ca resolves to the VPS where
app.py is running.
Local loopback and ports
------------------------
- Listener runs only on localhost:8080.
- Front end join requests are directed to http://localhost:8080/join?...
- This ensures that only the local machine can trigger the launcher.
- Netplay port:
* Default: 55435
* Can be overridden in lobby data.
- RetroArch uses this port to connect clients and hosts.
Security considerations
-----------------------
- Separation of roles:
* Backend is public-facing (retroarch.remz.ca).
* Listener and launcher are private, local-only.
- CORS headers in listener allow front end (remote domain) to call
localhost safely.
- Password field in URI provides optional netplay protection.
- Cloudflare provides DNS management and optional DDoS protection.
- No sensitive data is transmitted beyond lobby metadata and join
parameters.
- Admin Mode authentication:
* Password is never stored in front end.
* Verified only by backend via HTTPS.
* Nginx handles CORS preflight for /admin/login.
Validation checklist
--------------------
- DNS lookup for retroarch.remz.ca resolves to VPS IP.
- Accessing https://retroarch.remz.ca/lobbies returns JSON data.
- Front end successfully fetches lobby list from backend.
- Clicking "Join Game" sends request to localhost:8080 (not to VPS).
- RetroArch connects to host using specified port.
Summary
-------
Networking and DNS connect the public and private parts of the system:
- Backend is exposed via retroarch.remz.ca.
- Front end fetches lobbies from backend.
- Listener remains local on port 8080.
- RetroArch netplay uses port 55435 by default.
This separation ensures both accessibility and security.
-=-=-=-=-=-=-
7. Operations
=-=-=-=-=-=-=
Purpose
-------
Operations describe how to build, deploy, and maintain the system. This
section ensures that every component can be restored or restarted without
ambiguity. It also covers logging, troubleshooting, and common failure
modes.
Build, deploy, and restart procedures
-------------------------------------
- Backend (VPS: app.py + lobbies.json)
* Location: /root/retroarch-lobby
* Files: app.py, lobbies.json, venv/
* Start procedure:
cd /root/retroarch-lobby
source /root/retroarch-lobby/venv/bin/activate
nohup python app.py > flask.log 2>&1 &
* Restart procedure:
- Find running process:
ps aux | grep app.py
- Identify the PID (process ID) of the running app.py.
- Kill the process:
kill -9
- Restart using the start procedure above.
* Log file: flask.log (captures stdout and stderr).
- Set admin password before starting app.py:
export ADMIN_PASSWORD="your_secret_password"
- Verify admin login:
curl -i -X OPTIONS https://retroarch.remz.ca/admin/login
curl -i -X POST -d '{"password":"your_secret_password"}' https://retroarch.remz.ca/admin/login
- Front end (HTML lobby browser)
* Hosted as static files on web service.
* Deployment: upload updated HTML/JS to hosting directory.
* Restart procedure: refresh browser; no local build required.
- Listener (remz-listener.exe)
* Build commands (Windows):
rc remzlistener.rc
cl /EHsc remz-listener.cpp remzlistener.res /link user32.lib shell32.lib
* Deployment: copy remz-listener.exe to local machine.
* Restart procedure: exit via tray icon or Task Manager, then relaunch.
- Launcher (retroarch-launcher.exe)
* Build commands (Windows):
cl /EHsc retroarch-launcher.cpp /link user32.lib shell32.lib
* Deployment: copy retroarch-launcher.exe and launcher-config.json to
local machine.
* Restart procedure: no persistent process; runs per invocation.
Logs and troubleshooting
------------------------
- Backend logs:
* flask.log records all backend activity.
- Listener logs:
* Show incoming requests and URIs.
* Confirm launcher invocation.
- Launcher logs:
* Show config path, raw config, resolved core/game paths.
* Show full RetroArch command line.
* Show success or failure with error codes.
- If "Set Admin Mode" fails:
* Symptom: browser shows CORS error or 404.
* Fix: ensure nginx config includes OPTIONS handling for /admin/login.
* Symptom: "Invalid password."
* Fix: confirm ADMIN_PASSWORD environment variable matches input.
Troubleshooting steps
---------------------
- If front end shows no lobbies → check flask.log and confirm app.py is running.
- If join fails → check listener log for request, then launcher log for command.
- If RetroArch fails → check launcher log for missing core/game.
Common failure modes and quick fixes
------------------------------------
- Backend not running:
* Symptom: front end shows empty lobby list.
* Fix: restart app.py using the procedure above.
- Listener not running:
* Symptom: clicking "Join Game" does nothing.
* Fix: start remz-listener.exe; verify http://localhost:8080/ping.
- Launcher config missing or invalid:
* Symptom: launcher log shows "config not found" or "missing key".
* Fix: ensure launcher-config.json is present and valid.
- Core not found:
* Symptom: launcher log shows "Core not found".
* Fix: verify core DLL exists in coresPath.
- Game not found:
* Symptom: launcher log shows "Game not found".
* Fix: ensure game file exists in gamesPath.
- RetroArch launch failure:
* Symptom: launcher log shows "Failed to launch RetroArch".
* Fix: check retroarchPath in config; verify retroarch.exe exists.
Summary
-------
Operations ensure stability and reproducibility:
- Clear build commands for each component.
- Backend start/restart procedure documented with exact commands.
- Logs provide traceability for troubleshooting.
- Common failure modes have quick fixes.
This guarantees that the system can be maintained and restored reliably.
-=-=-=-=-=-=-
8. Appendices
=-=-=-=-=-=-=
Purpose
-------
The appendices provide quick reference material: exact file paths,
names, code snippets, and one-liner commands. This section is designed
for fast lookup during troubleshooting or restoration.
8.1 Exact file paths and names
------------------------------
- VPS backend:
* /root/retroarch-lobby/app.py
* /root/retroarch-lobby/lobbies.json
* /root/retroarch-lobby/venv/
* /root/retroarch-lobby/flask.log
- Listener:
* remz-listener.exe
* remzlistener.rc
* remz-listener.cpp
* launcher-log.txt (output log file)
- Launcher:
* retroarch-launcher.exe
* retroarch-launcher.cpp
* launcher-config.json
- RetroArch:
* retroarch.exe
* cores/ (contains core DLLs, e.g., snes9x_libretro.dll)
* games/ (contains ROM files, e.g., Super Mario World (U) [!].smc)
- Discord Bot:
remz_bot.py
bot-config.json (optional for advanced settings)
8.2 Copy-paste code snippets
----------------------------
- Backend start:
cd /root/retroarch-lobby
source /root/retroarch-lobby/venv/bin/activate
nohup python app.py > flask.log 2>&1 &
- Backend restart:
ps aux | grep app.py
kill -9
cd /root/retroarch-lobby
source /root/retroarch-lobby/venv/bin/activate
nohup python app.py > flask.log 2>&1 &
- Listener build (Visual Studio X64 Prompt):
rc remzlistener.rc
cl /EHsc remz-listener.cpp remzlistener.res /link user32.lib shell32.lib
- Launcher build (Visual Studio X64 Prompt):
cl /EHsc retroarch-launcher.cpp /link user32.lib shell32.lib
- Discord Bot run:
python remz_bot.py
Keep alive (Linux):
nohup python3 remz_bot.py &
8.3 Reference commands and one-liners
-------------------------------------
- Verify listener:
curl http://localhost:8080/ping
- Verify backend:
curl https://retroarch.remz.ca/lobbies
- Check logs:
tail -f /root/retroarch-lobby/flask.log
tail -f launcher-log.txt
- DNS resolution:
nslookup retroarch.remz.ca
8.4 Discord Bot quick reference
--------------------------------
Commands:
!setchannel #channel-name
!setrole Role Name
Requirements:
pip install discord.py requests
Security:
Keep TOKEN secret; reset if exposed.
Summary
-------
The appendices consolidate all critical paths, commands, and snippets
into one place. They serve as a quick reference for building, restarting,
and validating each component of the system.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
9. Discord Bot Integration (remz_bot.py)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Purpose and behavior
--------------------
The bot posts alerts for new Waiting Games from https://remz.ca/lobby into
Discord channels. Alerts include game details and a "Join Netplay Lobby" button.
Requirements
------------
- Python 3.9+
- discord.py and requests libraries
- Discord bot token
Setup
-----
1. Create bot in Discord Developer Portal
2. Invite bot to server with Send Messages, Embed Links permissions
3. Edit remz_bot.py and set TOKEN
Running the bot
---------------
python remz_bot.py
Linux VPS:
nohup python3 remz_bot.py &
Configuring alerts
------------------
!setchannel #channel-name
!setrole Role Name
Fallback: @here if role missing
Operations and security
-----------------------
- Polls feed every 10s
- Deletes old alerts when lobbies close
- Only Manage Server users can configure
- Keep token secret
Validation checklist
--------------------
- Bot online
- Posts alerts for new Waiting Games
- Deletes alerts when lobbies close
- Mentions role or @here
Summary
-------
The bot improves matchmaking by notifying communities in real time.
-=-=-=-=-=-=-
10. Conclusion
=-=-=-=-=-=-=
This documentation captures the entire RetroArch lobby workflow in a
clear, reproducible format. Each component — backend, front end, listener,
launcher, Discord bot and RetroArch itself — has a defined role and responsibility.
Together they form a stable chain:
Backend → Front end → Listener → Launcher → RetroArch
→ (Optional) Discord Bot
The bot accelerates matchmaking and strengthens community engagement.
Admin Mode adds secure, password-protected control for lobby management,
ensuring only authorized users can create multiple lobbies or delete lobbies
created by other users. This strengthens trust and reproducibility in the workflow.
Relay and password support extend the workflow to modern RetroArch builds,
ensuring compatibility with v1.21.0.
By documenting not only the architecture but also the operational
procedures, validation steps, and troubleshooting methods, this guide
ensures that the system can be maintained, restored, and trusted over
time. It emphasizes transparency, simplicity, and reliability—values
that protect user confidence and make the workflow sustainable.
With this reference, anyone can:
- Understand how the system is structured.
- Rebuild or restart components without ambiguity.
- Trace issues through logs and validation checklists.
- Keep the environment consistent and secure.
This conclusion marks the documentation as complete: a production-ready
resource that preserves the integrity of the setup and provides peace of
mind for future maintenance.
© 2025 Remz Domain