Flathub seems to ban the listing of new apps whose development was AI-assisted

[EhudKirsh]

I was going to open this post as an announcement 📢, but it seems that I lack permission to be allowed to do that.

At any rate, I dislike being the bearer of bad news, but there has been some drama in the Flathub community over the last week,
and it seems that Flathub may not allow publishing new apps on it whose development was AI-assisted. This will most likely include AeroFTP as well. It seems that this ban is strict, and includes using AI even for pull requests and writing documentation, not just coding.

I couldn't find a specific official link to share, so you might wish to look it up.

[axpnet]

Hi @EhudKirsh, thanks for flagging this.

Let me be fully transparent, since this thread may be read by Flathub reviewers as well.

On AeroFTP and AI

AeroFTP is a solo, open source project, and I use AI assistance heavily in its development. I am not going to hide that or relabel it as something else. Under Flathub's updated policy (the May 29, 2026 rewording of the LLM rule), that puts the app within scope of the restriction, and I accept that reading.

What happened earlier (January 2026)

I tried to submit AeroFTP to Flathub for the first time back in January, and I made genuine beginner mistakes:

• I opened an issue and two PRs in close succession, which looked like noise on the tracker.
• I removed the submission template on one PR, which is an automatic reason to reject.
• I let the AI write my review replies, including one long summary. To the reviewer that read as low effort, and I understand why.

I want to be clear about one point only: I was never trying to deceive anyone, and I tried to stay polite even when the exchange got harsh. But the mistakes above were mine and they were avoidable. It was my first time with the process and I was learning it.

On the new policy

I am not here to argue against it. The maintainers review an enormous volume of submissions, a lot of it genuinely low effort, and they are entitled to set the bar where they want. I respect the decision, and I am not going to try to game it or slip a submission through the cracks.

Where this leaves AeroFTP

The policy keeps one door explicitly open: mature, well maintained projects. That is the only route I would ever consider, and only if it genuinely fits, which would mean:

• a calm, stable release cadence sustained over several months (our earlier cadence was fast and churny, which is itself a red flag under the rules),
• a submission written by me, by hand, following the template exactly,
• and zero pressure on reviewers.

If that day never comes, that is fine too.

On distribution, the honest bottom line

Flathub is a nice to have for AeroFTP, not a blocker. The app already ships through AppImage, .deb, Snap, and the AUR, alongside Windows and macOS builds, so users can install it today through several channels. We are also working toward the Microsoft Store, once code signing is in place, and toward the Apple App Store once the build is stable enough. Once that official presence is in place across platforms, AeroFTP would also be a more obviously mature, well maintained project, and at that point I may revisit Flathub through the route the policy leaves open. For now I am deferring it rather than pushing on it, and putting that energy back into the app and its users.

Thanks again for raising this, and thanks to the Flathub team for the work they do.

[jing2uo]

Hi @axpnet — thanks for AeroFTP. The two-pane client with an encrypted local vault and rclone/WinSCP/FileZilla profile export is a genuinely useful combination.

I maintain FlatPark, a small community repository that offers Flatpak installs for desktop apps that aren't on Flathub, and I've packaged AeroFTP there. It uses Flatpak extra-data: it downloads your official AeroFTP__amd64.deb unmodified at install time and follows your GitHub releases. Nothing is rehosted or patched, and the app ID and AppStream identity are the ones you already ship inside the .deb.

flatpak remote-add --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak install flatpark com.aeroftp.AeroFTP

App page: https://flatpark.org/apps/com.aeroftp.AeroFTP

My testing is shallow, and I'd rather say so than pretend otherwise. I confirmed it builds, installs, launches, renders, and that the tray icon registers. I have no FTP, SFTP, WebDAV or S3 server to test against, so I never made a single connection — the transfer queue, the vault, keyring integration, the media preview and profile export are all untested by me.

So: if you have time to put it through real use, I'd genuinely appreciate knowing what breaks. And if you'd rather adjust the packaging yourself, a PR against registry/com.aeroftp.AeroFTP/ is very welcome — it's a small directory of YAML plus two shell scripts.

One decision worth your opinion: the sandbox grants no filesystem access by default, so the local pane browses the sandbox home and everything else goes through the file-chooser portal. Your own manifest ships --filesystem=home. Users can get that with flatpak override --user --filesystem=home com.aeroftp.AeroFTP. If you think that default is wrong for a file transfer client, tell me — you know the workflow better than I do.

And if you'd rather I not list it, just say so and I'll remove it right away.

[axpnet]

Thank you for packaging AeroFTP, and for asking rather than just shipping. I would rather co-maintain this with you than have it live outside my view, so I have taken it on from our side.

You got the three hard things right, and they are the ones that are easy to miss: building the whole Ayatana stack from source (our Tauri tray dlopens libayatana-appindicator and panics if it is absent, and the GNOME runtime does not carry it), WEBKIT_DISABLE_DMABUF_RENDERER=1 for the blank-window driver issue, and the tray socket through --filesystem=xdg-run/tray-icon:create.

On the sandbox default you asked about, I have opened a PR: flatpark/flatpark#98. The short version is that AeroFTP's local pane does not use the file-chooser portal; get_local_files calls read_dir directly, so without a --filesystem grant the pane shows an empty home rather than the user's files. I added --filesystem=home plus /media and /run/media, matching our own packaging and what FileZilla ships on Flathub. I will not pretend that leaves a tight sandbox: home access makes the confinement largely decorative, which is the norm for a transfer client but is worth stating on the app page rather than implying otherwise.

The same PR fixes a missing MimeType line in the desktop file, so the AeroFTP file formats associate correctly. That one was on us: Tauri does not emit MimeType, our .deb postinst adds it, and a Flatpak build never runs that postinst. The same gap was hiding in our AUR package, which I have now fixed too, so thank you for the nudge.

Dropping aeroftp-update-helper was the right call and needs no change: the in-app updater installs a .deb or .rpm through pkexec, which cannot work from a read-only Flatpak, and the app already falls back to notify-only inside a sandbox on its own. Your metainfo and your Categories=Network;FileTransfer; are both correct, and the latter is better than what our .deb currently ships. I have now fixed that upstream, so every Linux format carries Network;FileTransfer; from the next release, v4.1.3.

You asked to have the build tested against real servers, so I did that too and put the details in the PR: I installed the Flatpak, the extra-data unpack worked, the tray came up with no crash, WebKit rendered, the vault opened, and I made real FTP and SFTP connections from inside the sandbox. One thing worth a line on the app page: a Flatpak install does not inherit a native install's servers or vault, because the config path differs, so an existing user will see an empty list on first run and should not think their data is gone. From v4.1.3 the app handles that in place: on first run inside a Flatpak it offers to import an existing native configuration, copy only and with the vault still locked behind its password, so that empty first run becomes a one click import rather than only a note on the app page.