Further Discussion on this topic is continued on the Loomio discussion

Libre launchers

This document is a brainstorming around FLOSS games launchers. The rationale is:

Table of Contents

[ToC]

Ecosystem review

Existing projects

There's already quite a few projects in this field, so let's try to make a comparison table:

ClientMulti-platformSocialMultirepo ⁽⁰⁾Native UICompiledOverlayTranslationsRunners ⁽¹⁾
Athenaeum✅
MacOS, GNU		⚙️❌ ⁽²⁾
Flathub		✅
Qt		❌❌✅❌ ⁽²⁾
Lutris❌⚙️✅
GoG, Steam, Humble Bundle		✅
Qt		❌❌✅✅
GNOME Games❌❌✅
Flatpak		✅
GTK		✅❌✅❌
Gameshub❌❌✅
Steam, GoG, Itch Humble Bundle		✅
GTK		✅❌✅✅
AppImagePool❌❌✅ AppImages~
Flutter		❌❌❌❌
Plei? ⁽³⁾❌❌ ⁽⁴⁾
Steam, uPlay, Origin, Epic		✅
Tkinter		❌❌❌✅
itch✅
MacOS, GNU, Windows		❌❌
Itch		❌
ElectronJS		❌❌✅❌
retroarch✅
MacOS, GNU, Windows		❌❌✅
Custom		✅✅✅❌ ⁽⁵⁾
Spring✅
MacOS, GNU, Windows		✅❌ ⁽⁶⁾
SpringRTS		✅
wxwidgets		✅?✅❌ ⁽⁶⁾
KODI✅
MacOS, GNU, Windows		❌?✅
Custom⁽⁷⁾		✅?✅?

⚙️ means the feature is planned but has not been implemented. Ideally, we'd have links to issues describing plans/ideas about said feature.

⁽⁰⁾ Multirepo means the launcher can download games from multiple sources, potentially with different protocols. ⁽¹⁾ Runners are different programs to run the games (eg. emulators) on the same platform. Games obtained on the same repository can leverage different runners. ⁽²⁾ Athenaeum technically has different repositories and runners, but only one per platform (flathub.org on free systems, homebrew on MacOS) ⁽³⁾ Plei runs on Windows, not sure about other platforms ⁽⁴⁾ Plei supports multiple repositories, but only non-free centralized stores (Origin/UPlay/Steam..) ⁽⁵⁾ Retroarch supports multiple runners, but there is currently no runner for native games ⁽⁶⁾ SpringLobby only supports games from the SpringRTS engine. ⁽⁷⁾ OpenGL based fullscreen app (windowed mode possible)

The following clients were not included in the comparison because there's a simple frontend for a single store (eg. Epic Store), but could be forked:

The following clients were not included because they're a simple frontend for a single game, but show that there is a demand for such an updater/launcher even in FOSS games:

Feature wishlist

In this section, we make a detailed wishlist for features an ideal libre games launcher should have.

Games setup

Social features (optional)

Game library

Video streaming support

Alternative user interface

It would make sense to develop a backend-first games launcher, on top of which different UI frontends can be prototyped. Some features could be:

Games integration

In addition to providing features for games from the outside, some games could integrate with free launchers using a specified free protocol:

With a such protocol, it becomes possible (in addition to switching windows and/or an overlay UI) to have games integrate social interactions directly within their UI. This means that:

Libre games 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:

So we consider whether to serve a repository of our own.

Upsides:

Downsides:

PROPOSAL 1: 0install repository

Note: Maybe distributing AppImages on GNU/Linux and *BSD via 0install would be interesting, so that the games can be copied around when there is no network. On Windows and Mac, .exe and .app should do that already.

Since we aim to support multiple platforms, we need a cross-platform packaging format. The only candidate so far is https://0install.net/:

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:

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? (probably the second option)

In addition, a nightly cron job should run to publish nightly releases:

PROPOSAL 2: AppImageUpdate repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

PROPOSAL 3: Flatpak repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

PROPOSAL 4: GNU/guix repository

TODO: Does someone want to make a detailed proposal based on that?

NOTE: This package format is not cross-platform, so the proposal needs to account for that.

Additional considerations

GUI toolkit

What GUI toolkit to use determines how easy it will be to implement further features. Here's a comparison table:

FrameworkCross-plat.LightweightSocialUI OverlayImplementations
Qt✅✅❌ ⁽¹⁾✅athenaeum
GTK~✅❌ ⁽¹⁾✅gamehub
ElectronJS✅❌✅ ⁽²⁾❌ ⁽³⁾heroic, itch
Flutter✅~~ ⁽⁴⁾?AppImagePool

⁽¹⁾ Not impossible to implement, but harder than just embedded a 3rd party client ⁽²⁾ Via a web-based XMPP/matrix client + build in WebRTC for audio/video. ⁽³⁾ Until proven otherwise, it's assumed an electronJS application can't hijack focus from a running full-screen application ⁽⁴⁾ Flutter/Dart libraries for exist for XMPP and Matrix. Also see FluffyChat for Matrix.

Also worth mentioning, Electron functionality of desktop web applications could in fact be replaced by:

Social protocol

In order to provide excellent social features, we need to ues a social networking protocol. Here's a comparison chart:

ProtocolFederationEasy selfhostingTextVoiceVideoFriendslistExtensible ⁽⁰⁾Guest accounts ⁽⁵⁾Spaces ⁽⁸⁾
IRC❌ ⁽¹⁾✅✅❌❌❌~✅❌
XMPP✅✅✅✅ ⁽²⁾✅ ⁽²⁾✅✅ ⁽⁷⁾✅ ⁽⁴⁾❌
Matrix✅❌✅❌ ⁽³⁾❌ ⁽³⁾✅✅❌✅
Mumble❌✅✅✅❌❌~✅❌
Spring❌❌✅ ⁽⁶⁾❌❌❌✅ ⁽⁶⁾❌❌

⁽⁰⁾ Extensibility is needed to develop new features, such as matchmaking ⁽¹⁾ Federation in the context of IRC means something else, it's a closed federation to provide redundancy across servers, but does not enable users to communicate across networks ⁽²⁾ Audio/Video in XMPP ecosystem is provided by Jingle and/or multimedia bridges; Jitsi implementation is not standard, but some clients are working on interop (Conversations/JSXC/Gajim) ⁽³⁾ Audio/Video in Matrix is provided by third-party clients/protocols such as Jitsi ⁽⁴⁾ Guest accounts are provided via "anonymous login" ⁽⁵⁾ Guest accounts with limited privileges (can't send friend invites) could be useful to start a multiplayer game on a specific game without having to create an account first ⁽⁶⁾ Spring uses a customized IRC protocol with support for sharing current "matches" (servers) ⁽⁷⁾ XMPP supports basic presence information, but it's trivial to build advanced presence via the PubSub extension; see User tune for an example extension ⁽⁸⁾ Spaces are a sort of collective namespace, where permissions can be defined for the entire group/team, and some chatrooms can be affiliated to the space

Package/Repository standards

Maybe it would be useful to support several types of repositories? Or a single cross-platform format? Here's a comparison chart:

FormatCross-platformReproducibleBootstrappableSignaturesRepositoriesDelta upgradesImplementations
AppImage❌❌❌✅❌ ⁽¹⁾✅AppImagePool
Flatpak❌❌❌✅ ⁽³⁾✅✅athenaeum, GNOME Games
0install✅❌❌✅✅❌
nix/guix❌ ⁽²⁾✅guix✅✅❌

⁽¹⁾ AppImagePool uses a custom upstream feed, as well as a custom featured applications feed ⁽²⁾ Technically, guix and nix can build Windows application, however there is currently no support for Windows as foreign distro ⁽³⁾ Flatpak repositories are signed

The following packaging systems were considered, but not added to the comparison table:

Platforms/architectures to support

Below, we consider a list of platforms to support:

Below, we consider a list of architectures to support:

Anti-features (to avoid)

Priorities

This document is not exatly a specification for a future client project. However, if it must be interpreted like that, some features should probably be prioritized over others:

Some features described in the wishlist may appear to be less important to some people: