import launcher idea from pad
* collaborative anonymous editing, but list known contributors * https://scalar.vector.im/etherpad/p/!qLhNfILESSCaasbRWB_freedombox.emorrp1.name_launch Co-authored-by: infrared Co-authored-by: librebob Co-authored-by: poVoq
This commit is contained in:
parent
1e32a037eb
commit
c049dcf330
GPG Key ID:
DBCA65091F248E6C
|
|
@ -0,0 +1,198 @@
|
|||
<!-- SPDX-License-Identifier: CC0-1.0 -->
|
||||
|
||||
# Brainstorm about a libre-games launcher
|
||||
|
||||
## Media player UI (aka Steam big picture)
|
||||
- Lots of projects focussing on that especially in the Emulation space
|
||||
- Would be a nice feature to have
|
||||
- KODI would be probably the best platform, but running it in Window-mode looks bad.
|
||||
- KODI has a build in webserver a could be remote controlled via a web-interface / electron app
|
||||
|
||||
## Types of possible packages / repositories (for Linux)
|
||||
|
||||
Maybe it would be useful to support several types of repositories?
|
||||
|
||||
- Appimage
|
||||
- +: decentralized, PGP support, delta/differential upgrades
|
||||
- -: no repositories yet, no windows support, updates rarely supported
|
||||
- Flatpak
|
||||
- +: decentralized, some sandboxing, delta updates, deduplication, repositories, appstream data
|
||||
- -: some sandbox edge-cases make games suck with it (eg. to install mods), no windows support
|
||||
- 0install.net
|
||||
- +: truly cross-platform format for install/update, can interop with AppImages
|
||||
- -: we haven't really tested it, also no delta upgrades
|
||||
- Guix/Nix
|
||||
- +: reproducibility, security, easy to ensure that upgrades build
|
||||
- -: no integration for desktop files (menu entries) on foreign distro, no windows support (cross-compiling using mingw should be possible?)
|
||||
- Packages for every different distro (too hard to maintain)
|
||||
- tgz with statically linked binaries (AppImage is that, but better)
|
||||
- Snap (centralized rapository) not seriously considered because it is too centralized
|
||||
|
||||
## Frontend - Backend seperation?
|
||||
- Leverage existing CLI backend systems (which?)
|
||||
- Utilize existing front-end launcher type projects
|
||||
- Less integration and advanced features possible (why?)
|
||||
|
||||
## Own repository?
|
||||
|
||||
Should we provide a new repository for games, or reuse an existing one? There is already a number of games on Flathub/Snapstore, however:
|
||||
- we're not sure these packages are maintained by upstream or by a benevolent team of volunteers (risk of malware)
|
||||
- we're not sure these packages will receive updates (see above)
|
||||
- there are no packages for nightly updates or beta/RC releases
|
||||
|
||||
So we consider whether to serve a repository of our own.
|
||||
|
||||
Upsides:
|
||||
- Own repository would allow better curation and trust chain
|
||||
- we can add games that are not packaged elsewhere, and ensure all games we want to support are available through the same channel (not Flathub for one game, snap for another, etc)
|
||||
- More complete "service", not "just" another frontend
|
||||
Downsides:
|
||||
- really time consuming <-- really? should be a simple CI script
|
||||
- server costs <-- is there that many games to package? a very small VPS should do it, as long as it has enough RAM (~4GB should be enough for most games), need a lot of disk space though
|
||||
- cross compilation issues
|
||||
|
||||
### PROPOSAL 1: 0install repository
|
||||
|
||||
Since we aim to support multiple platforms, we need a cross-platform packaging format. The only candidate so far is https://0install.net/:
|
||||
|
||||
- releases for multiple architecture
|
||||
- source release with automated compilation instructions
|
||||
- PGP signatures for all package "feeds"
|
||||
- there's already a GUI for everything
|
||||
- non-stable releases (nightly, beta..)
|
||||
- multiple package sources
|
||||
|
||||
In order to reduce server storage/network costs, we should serve files over IPFS or Bittorrent. IPFS has a clear advantage, in that IPNS enables us to have a stable "feed" address with a corresponding PGP key.
|
||||
|
||||
On a high-level, the build system could operate like this:
|
||||
|
||||
- Keep a local cache of upstream versions to package, so that we know when an upstream release is new
|
||||
- Check for upstream updates (eg. via RSS), extract corresponding git tags
|
||||
- If upstream repository is signed, verify PGP signatures on commits (eg. `guix git authenticate`)
|
||||
- If an update was found, try to build for all platforms
|
||||
- If a platform does not build or run tests successfully
|
||||
- Publish the build log on the website
|
||||
- Inform admins via email, XMPP...
|
||||
- If a build was successful
|
||||
- Create the 0install manifest containing checksums for this new build
|
||||
- Add the new manifest to the application's feed
|
||||
- If one or more builds were successful
|
||||
- Sign the application's feed with the repository's PGP key
|
||||
- Publish the new feed and corresponding builds on HTTP and IPFS/IPNS
|
||||
|
||||
In case a release build has failed, it is expected that either our repository's build steps will be updated. In that case, all manifests for the current release should be unpublished, and the release process for that version starts anew. If the problem was upstream and they have to publish a new tag, a normal release process ensues and the previous version will only have the previously-successful builds published.
|
||||
|
||||
**TODO:** When updating our repository's build steps, should it rebuild all packages? Should we run a git diff to see which application's build steps have been altered, and trigger a rebuild for the last release for those?
|
||||
|
||||
In addition, a nightly cron job should run to publish nightly releases:
|
||||
|
||||
- Check for upstream updates on main branch
|
||||
- If upstream repository is signed, verify PGP signatures on commits
|
||||
- If new commits have been published, publish a new "nightly" release following the algorithm explained above
|
||||
|
||||
### PROPOSAL 2: AppImageUpdate repository
|
||||
- https://github.com/AppImage/AppImageUpdate
|
||||
- Decentralized and with delta-updates
|
||||
- Hosting own repo is basically just putting appimage files on a server
|
||||
- CDNs supported to lower traffic load on server (IPFS support feasible?)
|
||||
- Already supported by Suse open-build service
|
||||
- People can easily add their own 3rd party appimages (if those include the needed metadata)
|
||||
- (negative) No good front-end integration yet?
|
||||
- (negative) Appimages are Linux only
|
||||
|
||||
## Cross-platform?
|
||||
### Windows support?
|
||||
- Reality: even for libre games, most players are on Windows
|
||||
- In Windows the need for a launcher is even higher as there are no good alternatives
|
||||
- Windows sucks and we probably don't have any windows using developers
|
||||
- Difficulties to cross-compile (MinGW etc.)
|
||||
### Chromebook support?
|
||||
- Really increasing market share (at least in the US)
|
||||
- Lots of young players on school chromebooks, Minetest etc. probably popular
|
||||
- Has Linux binary support in some way, but not that easy? <-- it's a system similar to wine, enabled by the user in system settings
|
||||
- partial flatpak support https://flatpak.org/setup/Chrome%20OS/
|
||||
### Android support?
|
||||
- Completely different ecosystem, but some existing libre games have ports
|
||||
- Could be just an curated f-droid repository <-- an F-Droid build server is considerably more difficult to setup than any other kind of repository
|
||||
|
||||
## Text chat support
|
||||
- IRC:
|
||||
- Easy to include, but basic.
|
||||
- No good friend-lists like system.
|
||||
- No account required
|
||||
- No voice-chat
|
||||
- XMPP:
|
||||
- coverers all the needs and easy to host
|
||||
- Good friend-list feature and custom status messages
|
||||
- Good embeddable Javascript clients available (JSXC or maybe ConverseJS)
|
||||
- Less good Discord like web-chat (But Movim might be an option)
|
||||
- Built in p2p voice chat (possible server supported voice-chat in the near future)
|
||||
- JSXC: Embeddable, has WebRTC voice & video chat + screensharing, e2ee, sidebar for friend-list
|
||||
|
||||
- Matrix:
|
||||
- No ready to embed client?
|
||||
- Good friend-list feature
|
||||
- Rich content
|
||||
- More Discord like
|
||||
- Resource intensive to host an instance, clients are also resource-intensive
|
||||
- No (yet) built in voice-chat (I think 1 on 1 calls use their own protocol but not 100% sure about that <-- they use Jitsi integration for that)
|
||||
- Mumble:
|
||||
- Great audio-chat
|
||||
- Text-chat very simple
|
||||
- Mumble-web could be embedded
|
||||
- No friend-list feature
|
||||
|
||||
## Other ideas
|
||||
### Screen overlay features?
|
||||
- Is there a way to allow an easy to access screen-overlay like in Steam?
|
||||
## Video streeming support
|
||||
- Possible to include some sort of video recording /streaming support?
|
||||
- Quick video replay feature?
|
||||
- Screensharing via WebRTC might be easy to include
|
||||
|
||||
## Front-end
|
||||
### Native (qt or GTK etc.)
|
||||
- Fast and low resource
|
||||
- Need to build everything from scratch more or less
|
||||
- Cross-platform more difficult
|
||||
- Some existing Qt projects (Athenaeum, gamehub)
|
||||
### Electron based
|
||||
- Resource hogg
|
||||
- Easy to include javascript based systems for chatting etc. (Mumble-web, JSXC)
|
||||
- Nice existing game-launcher systems (Heroic launcher, itch.io)
|
||||
### Tauri https://tauri.studio/en/
|
||||
- Electron like, but more lightweight and with a Rust backend
|
||||
- No WebRTC yet (planned), kind of deal breaker if we want to support WebRTC audio-chat/screensharing
|
||||
- Possibly Mobile and WASM (PWA?) targets in the future
|
||||
### Spring lobbies
|
||||
- Not tied to spring games
|
||||
- multiple implementations to choose from (chobby, ...)
|
||||
- IRC-like chat, friends list
|
||||
- Version matching
|
||||
- No voice or rich content implemented
|
||||
### CLIM
|
||||
- Nerd points
|
||||
- ???
|
||||
- lisp lurker points
|
||||
|
||||
## Existing projects
|
||||
- https://flathub.org/apps/details/com.gitlab.librebob.Athenaeum
|
||||
- https://wiki.gnome.org/Apps/Games
|
||||
- https://tkashkin.tk/projects/gamehub/
|
||||
|
||||
## Relevant similar projects
|
||||
- https://github.com/prateekmedia/appimagepool (Flutter based Appimage store)
|
||||
- Spring lobby clients (SprintRTS engine specific)
|
||||
- Lutris (Fronend for multiple stores, emulators and WINE)
|
||||
- Airshipper (Game specific for Veloren. Updater and news feed reader)
|
||||
- Unvanquish updater (Game specific, only updater)
|
||||
- KODI (media station, mainly for fullscreen use. Games/Emulator support work in progress)
|
||||
- EmulationStation / RetroArch (Fullscreen, very emulation focussed)
|
||||
### Open-source store front-ends
|
||||
- Heroic launcher https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher (electron)
|
||||
- https://github.com/Dummerle/Rare (Native client, Python & qt)
|
||||
- https://github.com/sakshatshinde/Plei (Python)
|
||||
- itch.io app https://github.com/itchio/itch (browserbased)
|
||||
- Desurium: https://github.com/desura/Desurium (browser based?)
|
||||
### Other launcher concepts
|
||||
- https://github.com/AykutSarac/epic-games-clone (seems more like a student project, react based)
|
||||
Loading…
Reference in New Issue