You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We achieved a lot with the release of Launcher v2. We rewrote everything in Typescript, cleaned up the codebase, added Dolphin auto-installing for Netplay and Playback Dolphin for a unified experience, and rewrote the entire UI with a consistent theme and traditional app layout.
However, there are still some outstanding issues. For example:
Being dependent on the unmaintained electron-webpack has proved to be a pain point when wanting to upgrade to newer Electron versions.
Security is quite poor with nodeIntegration enabled everywhere, and not following Electron security best practices
Goals with version 3
With that in mind, we may want to rethink the app once again and aim towards these goals, in-priority order.
New template
ERB is a popular boilerplate which uses Typescript and React, and is built upon Electron 13. In addition, it supports contextBridge out of the box. It does not yet support Typescript inside of the preload.js but we might be able to solve that ourselves. This template has over 18k stars and appears to be well maintained. This could allow us better flexibility and maintainability in the future.
Security first
We should aim to put security first and follow best practices for security in Electron apps. This includes using contextBridge for exposing node functionality, enabling Content Security Policies (CSP), disabling nodeIntegration etc. We should no longer use any node-specific packages inside of the renderer process, and rely only on contextBridge.
File indexer
Update: We probably don't actually need to do this. We can achieve close enough behaviour by doing the following:
Add a button to re-index in the settings
Re-index on Replay Browser page load
Re-index on notification from Dolphin that a file is done writing to (WIP: Dolphin does not have this ability to communicate with the launcher just yet)
This is actually a prerequisite for the next goal, replay database. We want an efficient way to track a bunch of folders for changes, and update our replay database with the SLP file data. This indexing process can be potentially quite resource intensive and so we need a way to enable/disable the file indexing (and database updating) during games (check for Dolphin.exe running). Using Axosoft/nsfw (which seems like it would be faster than chokidar) inside of a node worker may be a good start.
Replay database
We didn't get around to adding this feature with version 2. With version 3 it would be nice to have finally add a replay database containing the game start block and metadata block, in a relational database. We can then add custom filters for finding games based off character or stage, player names, etc. We might potentially want to also expose endpoints for 3rd party applications to query the database.
Relay 2.0
We currently have the ability to expose live Slippi game data over a local server for 3rd party applications to tap into, also called the Console Relay. With Relay 2.0 we should be able to expose this data via WebRTC to allow applications over the web to be able to receive the game data feed. We may want to create some sort of permissioned system to allow websites to request access to the live game data, with some sort of prompt that shows up in the launcher. Using WebRTC will allow us to reduce the load on the Electron main thread since we don't have to actively maintain a websocket server.
The text was updated successfully, but these errors were encountered:
TODO Status
ContextBridge
and turning offnodeIntegration
Background
We achieved a lot with the release of Launcher v2. We rewrote everything in Typescript, cleaned up the codebase, added Dolphin auto-installing for Netplay and Playback Dolphin for a unified experience, and rewrote the entire UI with a consistent theme and traditional app layout.
However, there are still some outstanding issues. For example:
electron-webpack
has proved to be a pain point when wanting to upgrade to newer Electron versions.nodeIntegration
enabled everywhere, and not following Electron security best practicesGoals with version 3
With that in mind, we may want to rethink the app once again and aim towards these goals, in-priority order.
New template
ERB is a popular boilerplate which uses Typescript and React, and is built upon Electron 13. In addition, it supports
contextBridge
out of the box. It does not yet support Typescript inside of thepreload.js
but we might be able to solve that ourselves. This template has over 18k stars and appears to be well maintained. This could allow us better flexibility and maintainability in the future.Security first
We should aim to put security first and follow best practices for security in Electron apps. This includes using
contextBridge
for exposing node functionality, enabling Content Security Policies (CSP), disablingnodeIntegration
etc. We should no longer use any node-specific packages inside of the renderer process, and rely only oncontextBridge
.File indexerUpdate: We probably don't actually need to do this. We can achieve close enough behaviour by doing the following:
This is actually a prerequisite for the next goal, replay database. We want an efficient way to track a bunch of folders for changes, and update our replay database with the SLP file data. This indexing process can be potentially quite resource intensive and so we need a way to enable/disable the file indexing (and database updating) during games (check for Dolphin.exe running). Using Axosoft/nsfw (which seems like it would be faster than chokidar) inside of a node worker may be a good start.Replay database
We didn't get around to adding this feature with version 2. With version 3 it would be nice to have finally add a replay database containing the game start block and metadata block, in a relational database. We can then add custom filters for finding games based off character or stage, player names, etc. We might potentially want to also expose endpoints for 3rd party applications to query the database.
Relay 2.0
We currently have the ability to expose live Slippi game data over a local server for 3rd party applications to tap into, also called the Console Relay. With
Relay 2.0
we should be able to expose this data via WebRTC to allow applications over the web to be able to receive the game data feed. We may want to create some sort of permissioned system to allow websites to request access to the live game data, with some sort of prompt that shows up in the launcher. Using WebRTC will allow us to reduce the load on the Electron main thread since we don't have to actively maintain a websocket server.The text was updated successfully, but these errors were encountered: