Flathub publishing

[tinywrkb]

I submitted a draft Notion Enhanced Flatpak packaging to distribute the app to Linux users via Flathub.org.
Like other Flatpak packaging, it would be best, and it's even the official policy that the application's developer(s) will maintain its Flatpak packaging, but seeing the low activity here, I decided to move forward and at least submit a proof-of-concept packaging. Please let me know if any of the developers here would like to take over the Flathub submission.

I'm still evaluating the application, the maintainability of the Flatpak packaging, and if this is something I would be able to maintain in the long run, and these are why the submission is a draft.
In its current state, packaged with Electron 11, it's not going in. I need Electron 14 or newer to display CJK characters correctly with my system CJK font.
I'm running locally Electron 18 with Notion 2.0.27, though not without issues, and I'm not sure yet if I can resolve all of them. Anyway, I'm digressing.

To avoid possible license restrictions, this Flatpak packaging does not distribute the sources of the original Notion application. Instead, it uses the apply_extra step to download the original application from Notion's servers during the installation of the Flatpak app on the user's system, extract the needed files, and apply the enhancements.

The packaging need to comply with Flathub's policy of sandboxed compilation/packaging without network, so we carry package.json and package-lock.json for the enhancer and Notion, and install Node modules in offline mode.
This added complication is why the Flatpak packaging of some Electron apps just repackage a binary release instead of building from source, but that's not really an option here, considering the usage of Notion's sources.

To avoid a large download to the user's machine with unoptimized Notion's node_modules folder, and refrain from running an electron-builder packaging operation on every update on the user's machine, I limited the apply_extra step to mainly extracting Notion's sources and running the enhancer. So far, I don't see any drawbacks using this method.

Only Notion Enhanced is packaged. I don't see any benefit of having vanilla Notion repackaged, which even might confuse users to think that there's some official Linux Notion app.

Please let me know what you think. Should I move forward with this? Does anyone want to take over the submission?

[dragonwocky]

In its current state, packaged with Electron 11, it's not going in. I need Electron 14 or newer to display CJK characters correctly with my system CJK font.
I'm running locally Electron 18 with Notion 2.0.27, though not without issues, and I'm not sure yet if I can resolve all of them. Anyway, I'm digressing.

When the notion-enhancer updates to the latest Notion, this won't be a problem.

To avoid possible license restrictions, this Flatpak packaging does not distribute the sources of the original Notion application. Instead, it uses the apply_extra step to download the original application from Notion's servers during the installation of the Flatpak app on the user's system, extract the needed files, and apply the enhancements.

The packaging need to comply with Flathub's policy of sandboxed compilation/packaging without network, so we carry package.json and package-lock.json for the enhancer and Notion, and install Node modules in offline mode.
This added complication is why the Flatpak packaging of some Electron apps just repackage a binary release instead of building from source, but that's not really an option here, considering the usage of Notion's sources.

To avoid a large download to the user's machine with unoptimized Notion's node_modules folder, and refrain from running an electron-builder packaging operation on every update on the user's machine, I limited the apply_extra step to mainly extracting Notion's sources and running the enhancer. So far, I don't see any drawbacks using this method.

If it works, it works. However, for consistency with the other distributions of notion-repackaged and simplicity/reliability of installation, it would be ideal to distribute a binary. As far as I'm aware, Flatpaks are predominantly/often community maintained redistributions of apps (e.g. Spotify), so it wouldn't be unusual, + if we haven't had license problems with other distributions of the notion-enhancer yet I don't see why we would with Flatpak.

Only Notion Enhanced is packaged. I don't see any benefit of having vanilla Notion repackaged, which even might confuse users to think that there's some official Linux Notion app.

Having vanilla Notion repackaged is just as worth having enhanced Notion repackaged - as per my responses above and below this one, if we're distributing one we might as well distribute the other. If Notion eventually does build an official Linux app, ideally that would replace the notion-app packages everywhere.

All our other Linux distributions are split into a vanilla notion-app package and an enhanced notion-app-enhanced package. I'm not sure of the standards for Flatpack package names/ids, but it would be good to be consistent here.

Please let me know what you think. Should I move forward with this? Does anyone want to take over the submission?

@tinywrkb we would like to take it over, yes. The low activity here is not a permanent state, just for the near future while I'm busy with my final year. However, until the notion-enhancer does update, I'd prefer to hold off on additional distribution methods - the current range of distribution options covers all supported platforms, any others are just a matter of catering to user preference.

[tinywrkb]

Thanks for responding.

if we haven't had license problems with other distributions of the notion-enhancer yet I don't see why we would with Flatpak.

This not how this works. You need explicit authorization for distributing a proprietary app from its original developer as part of the terms of use or request it.
This is a mandatory policy set by every distro.
Apparently, it was discussed before with Notion, and it was not approved.
Without this, we have to use the apply_extra workaround, which helps us to avoid distributing the proprietary package.
The fact that Notion didn't complain yet about this doesn't mean that bundling Notion sources and distributing them isn't questionable.

In any case, I'm not going to argue about the legality of this, but I'll just say that I expect that a Flatpak packaging that download unauthorized bundle of repackaged Notion app, with changed or unchanged Notion's sources, will not be approved unless there's explicit authorization from Notion.
On the other hand, the suggested packaging that I created, downloads the original application during the installation step. It does not distribute Notion's sources, and it does not download an unauthorized repackaged Notion app.

we would like to take it over, yes

Alright, I closed the submission request.

[dragonwocky]

This not how this works. You need explicit authorization for distributing a proprietary app from its original developer as part of the terms of use or request it.
This is a mandatory policy set by every distro.
Apparently, flathub/flathub#1989 (comment).
Without this, we have to use the apply_extra workaround, which helps us to avoid distributing the proprietary package.
The fact that Notion didn't complain yet about this doesn't mean that bundling Notion sources and distributing them isn't questionable.

In any case, I'm not going to argue about the legality of this, but I'll just say that I expect that a Flatpak packaging that download unauthorized bundle of repackaged Notion app, with changed or unchanged Notion's sources, will not be approved unless there's explicit authorization from Notion.

I know. Sorry, I wasn't very clear in my last message. We do have authorisation to modify and redistribute their app under the notion-enhancer/notion-repackaged project as far as I'm aware (screenshots below are from a conversation with a member of Notion's support team in December 2021, and their ToS hasn't changed since). I'm not looking for any legal trouble, and I usually re-contact Notion to confirm before any major releases.

[tinywrkb]

Oh! That's great, and makes packaging much simpler.

[tinywrkb]

Until this will be published on Flathub, I uploaded my current Flatpak packaging, so anyone who wants this can easily build and install the app.
This is Electron 18 and Notion 2.0.27, and as far as I can tell, there are no regressions.
Except for this change suggested by @l782993610, the rest of the changes in the included patches are my own, though there isn't much in there.

[Skaldebane]

Hi there! Any updates on this? Was trying to install notion-repackaged on Fedora using the yum repo, but apparently the server fails at 60% (while downloading) on all mirrors for some reason. I can install the released .rpm from the releases here, but I'd like something that auto-updates. And hell yeah, Flatpaks are much much better.

#108 addresses the dnf download issue.

[ItsJamie9494]

Something I'd like to mention is, with publishing to Flathub, there's two things that can be done to assist with this process:

1. Electron Builder includes the ability to create Flatpak single-app bundles, which can be useful as a distribution mechanism. I can write a PR to provide support for this with your current build configuration, if this is desired

2. Flathub requires all manifests be stored on the Flathub GitHub organisation. To make this easier, as well as integrate smoothly into your current build system, an approach that can be taken is to create a Flatpak manifest that extracts the notion-repackaged/notion-enhanced AppImage or Deb, and places the files in the proper location. The reason I like this method is it makes the manifest much cleaner, requires one source, and has a very easy way to automate updates (the only file you'd have to change is the AppImage source, and since you use Github Releases, Flathub has an automated tool to make PRs for new releases)

I have a working Flatpak manifest using this method that I would be willing to send or include in the aforementioned PR, which, when added to Flathub, will automatically create PRs and require very little maintenance.

[tinywrkb]

Bundles have limitations, like the missing extensions support, and I don't think these are of any use for Flathub publishing.
It seems like Flathub will allow direct uploads, which will solve the discrepancy of developers using Frameworks that require networking during the build process, while Flathub CI builds offline.

[ItsJamie9494]

Correct, bundles aren't used for Flathub publishing. They can be useful as an alternative method for downloading the app (similar to AppImages), but AppImages cover that area pretty well.

I'm not sure about Flathub allowing direct uploads, but the general way of creating Flatpaks on Flathub is to use vendored packages as a source along with the source code, or to provide a pre-built version and extract it to the proper locations (which, as I mentioned, can be done easily by using the AppImage from Github Releases and extracting it properly)

[tinywrkb]

I'm not sure about Flathub allowing direct uploads

Flathub in 2023

[ItsJamie9494]

Ah, thank you. Yeah, that's interesting. At the moment, that's not available though, so I don't think we should try and wait