GeopJr
commented
1 month ago Hello! Let me start off by saying that I am NOT part of the Flathub team and I do NOT know the exact roadmap.
Is there a pathway to us having control over the flatpak building process while still being listed on FlatHub?
As of right now, no.
The easiest way to better understand the relationship between flatpak and flathub is fdroid. Like the fdroid repo, apps need to be built on their servers to be published on it. Flathub is far less strict however, this is why the current setup is allowed (of having a bot update the release from github releases and instead of building from source, it extracts the deb file).
Like the fdroid app/platform, flatpak allows you to create your own repo and self-publish your app. Users then refresh your repo to get updates etc. Fedora does this for example.
From my (outsider) understanding, there are plans for self-publishing on flathub, but there hasn't been any progress since https://discourse.flathub.org/t/is-it-possible-to-publish-a-self-contained-flatpak-file-to-flathub/2083/2
If we take over the building of the flatpak will the flatpak still be available through Flathub or only on a self-hosted page?
Nothing prevents you from maintaining both a flathub build and a self-hosted one, but otherwise the same issue as above applies.
Just to clear up the docs confusion a bit, the CI is for building flatpak bundles. These are not attached to a repo, users won't get updates automatically, they'll have to download the next update manually.
It can deploy to repos but only to flat-manager ones (https://github.com/flatpak/flat-manager), and definitely not flathub (since it doesn't support self-publishing). Flat-manager is the 'official' repo server, but IMO it's a bit too much for self-publishers. It requires a database and it's a full on server. In comparison, https://github.com/andyholmes/flatter is static and can be hosted on GitHub pages (note that flatter's github action builds the flatpak itself). (example flatter repo https://valent.andyholmes.ca/)
With that said, my personal suggestion would be that, while signing builds is important, users might not be very comfortable with adding another repo just for a single app and it will impact app visibility (aka it obviously won't show up on flathub and linux stores (unless users install the repo, but they need to know of Session already and actively look for it)). Security-wise, the flathub infrastructure is very transparent, from the building process (e.g. https://buildbot.flathub.org/#/builders/6/builds/129962) to the manifests (https://github.com/flathub/). Plus, if you keep the current setup of extracting from the deb, you could add a step to verify the build I guess.
Whatever the final decision might be, moving forward, I do have some unrelated things to consider:
- Attempt to build from source. This can be a tough one considering the amount of modules etc but it would build for aarch64 too and would reduce the middle-people users have to trust (github, github actions, oxen, github releases). But that obviously has its own disadvantages like signing
- Figure out #67, last time I tried, electron would still not use the portal for saving files
- If #67 gets done and Session ends up using the portals, then we can finally get rid of the
homepermission and make it completely sandboxed (note that I am not sure how ~/.session (or whatever the folder with the tokens is) would play out, we might have to open a hole for that so current installations don't break) - And lastly the metainfo file should be maintained upstream. It's a metadata file for stores. Specifically, the releases section should probably be filled on each update upstream with the changelog, so it shows up in stores
Let me know if you need more info on anything, however, for flathub related issues you are most likely to get accurate information on the forum https://discourse.flathub.org/
Aerilym
I'm part of the Session Desktop team and an avid user of the flatpak so I'm looking at getting the building and distribution process moved into our control. I'm following up on #81 and specifically to a comment left by @GeopJr:
I've done some digging and it seems the suggested method on Flathub is to use this "Flatpak Builder" github action to do the flatpak building and deploying?. I've not dealt with building a flatpak and publishing it to Flathub before and I'm a little confused by some of what I've read in the docs. If we take over the building of the flatpak will the flatpak still be available through Flathub or only on a self-hosted page?
Here are the few places in the docs that have led me to believe Session wouldn't be on Flathub anymore:
The after submission section of the Flathub docs implies the only way to get on FlatHub is via a PR which puts the manifest into the FlatHub org (which is what this
flathub/network.loki.Sessionrepo is)The publishing section of the flatpak docs also seems to separate being on Flathub and self-hosting.
Ideally we'd like to have it available on Flathub as its a good point of distribution (that's what I use for a lot of my apps), but as @GeopJr mentioned
"due to the nature of session (privacy & security), [they'd] find it reasonable if [we'd] want to take over the whole process.". So to start, I'd love to gather more information so we can make a more informed decision about what to do going forward. Is there a pathway to us having control over the flatpak building process while still being listed on FlatHub? Thanks.