@girish said in Proposal: The CUR - Cloudron User Repository:

App packages listed on the current App Store are all open source

Confluence is not open source.

I should have been clearer... I meant the packaging source code itself is opensource (i.e the docker file and the tests) but not the apps themselves. We actually many apps that are not open source - emby, teamspeak, the minecraft apps, the pre-installed smtp plugin in WP (was not opensource, but i have switched it to an open one now), probably forgetting more.

Confluence is not open source.

That I believe is correct however I believe they allow third-party packaging like this.

App packages listed on the current App Store are all open source

Confluence is not open source.

I'd still like the ability to have a private file repo and http(s) based installs from things like Surfer.

To generate the app from a git repo, there could be a bundling script like you mentioned.

Updates manual, but at some point I see feature requests to be more like package repositories with tools to scan for all available updates.

That is a big plus for Cloudron managed apps and kudos to the @staff team here.

If your intentions are, as @BrutalBirdie initially said, to be able to allow more package testing while those packages are still under development, then I think adding support for what @girish mentioned is great. Not for technical sake, but to actually serve the purpose. It makes no sense to build something like a 1-click install way for people who cannot actually provide app package testing. (Just a slight hint to the discussions Archlinux maintainers had in the past with the AUR wrapper script developers...this was and still isn't a everyone-is-happy situation)

I understand the analogy is not to be taken 1to1 but just wanting to give some input from that perspective as well, since I do think it is a good analogy to what was suggested.

Also to get a bit more focus rather than the big picture, the mentioned examples of Valheim and GTA game servers, may actually be treated differently than more critical apps with personal or business data

This way the cloudron admin could add another data source to the "App Store" on his Cloudron. Apps from that source could show in a dedicated category, potentially with a disclaimer above.

Plus points if the address would allow password protection (so that one could use an auth enabled surfer instance to host the file).

This is how the portainer template looks like:
https://github.com/portainer/templates/blob/master/templates-2.0.json

Then all you would need is a "third-party" app store site for users to post on, which I can make if internal workload is too much. (not as an app but something someone can host for users to go to to see third party apps and such.

So.. if let's say there was a command "cloudron bundle" or something and it outputs a foo.app which is really just a JSON file which is the normalized manifest and the last built dockerImage, would that be good enough ? For the user, a user can just paste a public URL that contains the file and we can install it.

Could you please list all the stuff your registry provides to the Cloudron server in order to list and install apps? The manifest, the path to the docker image, what else?

Ideally, if we can figure a way by which a user can easily install an app completely outside our supervision, either by pointing to a git(hub/lab) OR maybe the user can upload some "package" file, then it's easier for us to implement this.

Of course, if there is no way out, we have to consider putting in our database...

My 2 cents on how this could be implemented the most easily:

• Add another "tag" on the Cloudron app database, besides "unstable". Maybe we could call it "WIP", "community", or "alpha" ?
• Re-allow normal users to publish with the Cloudron CLI, but by default (if they are not cloudron staff), their apps are tagged as "community".
• Add a setting in the Cloudron admin interface, that allows showing "community" apps in the app store. Of course, there would be proper warning alerts that tell you this is not supported & such. Maybe it could even be a bit like android developer tools, and need a secret click combination to be displayed or something, to make it clear that it's not for everyone.

I don't think this would be to much work for the staff, and I believe it would cover most, if not all, use-cases.

When building an image: the CloudronManifest.json is in a git repo. the built docker image is stored in ~/.cloudron.json. When publishing to the store or installing on Cloudron these two things are merged and it's essentially just the manifest with dockerImage property.

Any ideas on how we a developer can create this merged blob so that a user can upload this merged blob? Updating the CloudronManifest.json in-place would make it appear in git diff all the time which I think is not desirable work flow.

Can we merge the build app with the registry app so that this can happen?

Perhaps the other way would work too, add what's needed to the registry app so it can pull, build and install within it's container and then push to any cloudron from there.

(Making a separate repository like AUR with search etc is a lot of work...I think. Maybe we can hack something in our database to mark something as AUR, not sure)

This is actually why I began the Non App Store Apps repo and forum post. You're more than welcome to contribute to the repo, or send me details about the apps you packaged and I can update the forum post to reflect those.

That being said, I do think this is a nifty idea. How do you see this being built out? Maybe there's an 'official unofficial' internal Cloudron Docker where some development can occur which would make the images exposed to other devs?