Verified can mean a lot of things, but I think that we’re giving off the wrong message by verifying commercial applications who are completely community maintained and who hardly work in the first place due to negligence from their actual developers.
The biggest example of this right now, is Discord: The state of Discord on Linux is poor and upstream is not engaged with the maintenance side of this package in any way. They use outdated libraries that actively require workaround, they don’t properly support system fonts and the majority of their functionality only works by removing all sandboxing since they haven’t implemented a single xdg-portal.
It gets even worse though… because although Discord is now ‘verified’, package maintainers still can’t inject certain library fixes because that would violate the EULA of Discord. These community fixes are available on the Arch AUR repository, but their ‘verified’ package lacks them.
In summary, I feel that ‘verified’ is misleading and that customers might expect too much of this app.
- Developer publishes app themselves
- Developer approves third-party effort
- Developer provides source and documentation to build
- Product has some base level of quality
- Wayland support
- File-browser portal support
- Proper localization support
Keep in mind, I don’t want to shit on Discord specific, it just happens to be that this application is very prominent, while also having 50+ known issues with the Flathub package.
While Flathub should not be the arbiter of quality, we should stop community-packages from getting too much cloud. Verified needs to mean that the people behind the application actually care, and that should be represented in the quality of the package.
I appreciate that there are some things that are unclear or frustrating around the combination of commercial and verified apps, and that’s an area we should definitely aim to improve expectations and processes. Your proposal around requirements for verification are interesting, but I’m not sure how realistic they would be to enforce.
In the case of Discord specifically, they’ve actively taken an interest in improving the Flatpak. I think the biggest growing pain as you’ve identified is that it’s an example of a community-submitted and -maintained manifest for a proprietary app that is transitioning into something that Discord themselves want to get behind and promote. However, I see this as a net positive as it means we have attracted Discord to come to our platform; the next step is to support them in doing things the right way, whether that means allowing integrating those library fixes (which if they are signing off on, should be acceptable for “their” manifest), or better, having them fix it upstream in their own builds. I know that as a company they don’t have significant resources assigned to Linux in general, but we can help demonstrate that Flatpak is the best way forward and deserving of what resources they can justify internally.
Something to remember in these cases is that half of the work in building a vibrant, compelling, and lasting ecosystem like Flathub is social rather than technical; we need to work with app developers like Discord to justify why they should spend their time catering to the platform and do our best to support them, which in the end will of course make their product better; but importantly, those efforts make our ecosystem better and more sustainable.
Eventually the goal should be to have Discord build the Flatpak out as part of their regular build and release process. I know several Discord employees are already using the Flatpak, and they’re excited to move forward to improve it. Stripping verification of com.discordapp.Discord because we have just begun a transition in maintenance doesn’t seem like a good path forward, especially when we are engaged with Discord and know they’re just getting started with this transition.
The biggest and outstanding issue with Discord on Linux is the Screen Sharing that has been left unfixed, despite community demand left ignored and unfixed for 4+ years along with critical security vulnerabilities of using outdated CEF libraries, but with community workarounds can mitigate these vulnerabilities by repackaging Discord with newer versions of CEF and Electron.
Screensharing is a critical component feature of Discord and the fact that you can’t screenshare on Linux properly goes to show their lack of interest in acknowledging and actively working on fixes to address these issues. So what’s the problem with Screenshare on Discord for Linux?
The problem is that while you CAN screenshare things on your desktop on Linux, you cannot stream audio alongside it capturing audio of the application or desktop you want to share. No proper audio support for screensharing, the only audio you get is your Input for microphone device and Output for your chosen audio output device. Community workarounds have lead to many different attempts to get desktop/application audio routed into Discord using custom created audio sinks so you can get desktop audio with Screensharing when it’s active. But many of these workarounds are often quite buggy and unstable, especially when you’re messing around with ALSA or PulseAudio as you may have unintended effects and bugs when trying to create an audio sink specifically for Discord to capture desktop audio, which by the way has to route through your Input source selected in Discord, which means you can’t use your mic AND screenshare WITH audio, and this is a very ugly and buggy workaround. Other issues stems from audio not being level and spiking in audio levels, in my many testings found that even when you disable the audio filters within Discord just for the Input source, even with Krisp or noise suppression OFF the audio levels will still fluctuate.
There has been demand for Wayland support in Discord because it works better for capturing Desktops and Windows a lot better and not have as many issues for capturing full desktop screens or windowed applications. There’s also demand for Pipewire support in Discord, which is seemingly a better experience for all with Pipewire, but even with Pipewire support baked in, it’s not going to solve the screensharing issues on Linux right away, but it’s a step in making it work. Pipewire handles multimedia routing and pipeline processing, and is a low-level multimedia framework so you can capture and playback audio and video with minimal latency, and can work with PulseAudio, JACK, ALSA, and GStreamer applications, and top of that you’re able to run the application sandboxed running with Pipewire support as a Flatpak, which in theory will work out the box with no configuration required.
Lastly injecting library fixes to Discord does NOT violate EULA, since it’s not modifying Discord as a service, it’s only the package software in which it runs on and is purely client side and doesn’t externally modify or disrupt Discord services in any way, you’re just telling Discord as an application to run with different and newer libraries instead of old and outdated ones which is only half the problem Discord has on Linux. All these client mods and patches ARE the community workarounds to the many issues Discord has because the community is sick of waiting around for a fix that may or may not even come. Not doing anything drives the community to make changes themselves and work on solutions that will hold over until a proper patch fix is made, of course these people don’t have internal documents on how Discord works or how to implement native features of the client itself without causing other issues.