Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launcher v3 #222

Open
2 of 4 tasks
vinceau opened this issue Aug 24, 2021 · 0 comments
Open
2 of 4 tasks

Launcher v3 #222

vinceau opened this issue Aug 24, 2021 · 0 comments

Comments

@vinceau
Copy link
Member

vinceau commented Aug 24, 2021

TODO Status

  • Migrate to ERB
  • Improve security using ContextBridge and turning off nodeIntegration
  • Replay DB Replay Database #178
  • Relay 2.0

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:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant