Hm yeah I think it might be better to instead create some kind of official path for publishing extensions in AppCenter

Sure if you want I'll start working on some kind of ExtensionsBackend in AppCenter. Would something like this be accepted? If not I can just go to flathub to make it less of an "official" feature with appropriate expectations 🤷

@leolost2605 I think we have a few layers of problems to think about:

Most important is that we don't have any API guarantee for anything that currently uses extensions and it's probably worth considering if we want to create the expectation of an extension API. We've broken API a lot in Code for example, the panel API will break soon when we port to GTK 4, and settings API has also broken and I'm planning to break it again.

AFAIK the only 3rd party extension for settings has been tweaks which imo should be its own separate app. We originally had the idea that OEMs might write extensions for settings but this never materialized and they typically ship separate 3rd party settings tools. Another one of the driving reasons that we used extensions was because we were used xembed originally to make up for the fact that we didn't have all of our own settings panes. So this decision is rooted in some ideas and constraints that we don't have anymore and it might be worth reconsidering the value of even having extensions at all in settings.

So I think the first thing to think about is which things do we even want to support extensions in.

Another issue is that peas extensions run in-process which makes them a security and stability problem and I'm not sure how feasible it is to distribute them in Flatpak. Not distributing them in Flatpak would create further distro lock in which is a major trade off to consider.

For the panel, if we're considering supporting 3rd party extensions, we should probably support a dbus API so these can be out of process rather than supporting in-process extensions. Which practically probably means just supporting ayatana OOTB. I don't feel great about adding 3rd party indicators because apps should really be using more purposeful API and historically we see a lot of abuse here, but I'd rather go down that road because it's at least theoretically cross-distro and already in use.

Which kind of brings up another point about being good open source citizens and we should be doing our best to make sure API we encourage developers to adopt is not distro locked and something we can at least propose to freedesktop.

I do think there is merit to making more things extensible though. We still have gaps in our portal coverage which would solve some issues with indicators. I think there's value in considering some kind of ongoing task or activity API like iOS which would solve more of the gap of what developers want from indicators. We probably could/should support some kind of search providers API like the GNOME one maybe. I'm not sure what other demands for extensibility there are but we should definitely look at those and see if we can solve them in a way that's cross-desktop and out of process