Cloudron Community App Store - Publish your app

[girish]

I made a fix now to make the listing show the packager* fields from the manifest (and not based on the OIDC login). The OIDC login is "private" and was used by mistake.

[fbartels]

I see that store is already starting to fill up. I think the individual app listing could use an entry to the source code of the app. Currently the links to website/documentation often go to the upstream projects.

Some apps, for example https://ca.cloudron.io/app/matrix-whatsapp-bridge, use the author field to link to a source repo.

Maybe instead of the "contact" value

[girish]

We can use packagerUrl for linking the source repo. I don't think people creating websites for packages anyway. I will adjust the pages to show this link separately. And the contact email can be a link to the packagerName.

[timconsidine]

As the list builds (already doing so), it will become not so easy to identify additions. I am wondering if there are some simple hacks that can be applied :

• show a total of number of apps listed (user : oh, it was 31, now it's 33, let me check what was added)
• optional sort by updated date instead of alphabetical (not to monitor whether an installed app update is needed, just to see what is new/changed)

I would like to emphasise the word SIMPLE. I don't want to suggest complex work. The page works really nicely as it is.

[girish]

@timconsidine done, added a basic filter and app count as well

[robi]

@girish Can you wrap or proxy the ca.cloudron.io store just like you do the appstore for every cloudron?

This would allow for no copy-pasting the versions file manually, and have a button-click install for community apps that are registered.

Thoughts?

[jdaviescoates]

This is great, but please could the packager name link to their user profile in this forum.

Or add an additional link to the relevant user profile on this forum (where one exists).

And ideally pull in any forum badges "App Dev" "Translater" etc too.

And possibly their forum "reputation" score too.

And their Cloudron forum join date.

Basically as much extra info as possible that helps people gauge a little more how experienced, reliable and invested in the Cloudron ecosystem they are.

Oh, and also and Added on date above or below the Updated on field.

Personally I'll not sure about the packager links going to email. As a packager I wouldn't necessarily want my email there. As a user I'd personally much prefer to contact them on here, either via a chat DM or in an appropriate forum thread.

[girish]

@jdaviescoates I think the email is not great as well. Previously, we had some vague fields like contactEmail and author. I have deprecated these now. I have gone ahead and added packageUrl (as @fbartels suggested, which can be say some github repo or some package website) . There is also packagerUrl (extra 'r'!) which can be a link to I guess the user's forum entry.

Now, to tie in form reputation/badges etc is out of scope for the moment for the community store. I think if people fill up the packagerUrl correctly, this can be determined by the end user. But let's see, these new fields require Cloudron 10 first and then the community app authors to fill in the field. Happy to accept future contributions for getting reputation etc.

(We also didn't want the community store to have profile fields like forum url etc intentionally i.e fields outside the versions and manifest fields. This would break the whole decentralization aspect if we have to maintain all this in a central place).

[timconsidine]

ooops

You have reached the maximum number of apps.

Please sir, can I have some more ?
(after Oliver Twist)

[girish]

@timconsidine done, it's 25 now .

[fbartels]

There seems to be a parsing issue with the recent changes:

It is cutting off the first two characters it seems.

[girish]

@fbartels the changelog file is meant to be like:

[x.y.z]
- Change 1
- Change 2

So the first chars in each line are stripped (you can also use * etc). I have deployed a fix to strip the chars if first two are not those sequences.

[fbartels]

@girish ah, that explains it then. Seeing I was not the only one to that made that mistake i welcome the fix to detect the bullets automatically.

[robi]

robi said:

@girish Can you wrap or proxy the ca.cloudron.io store just like you do the appstore for every cloudron?

This would allow for no copy-pasting the versions file manually, and have a button-click install for community apps that are registered.

Thoughts?

none?

[girish]

@robi missed that comment. are you referring to embedding community app store inside Cloudron dashboard?

[fbartels]

@robi I really like the idea of making it easier to install these, but a deep visual integration or proxy directly inside the main Cloudron UI might clash with the team's goal of keeping community apps distinct from official ones.

Instead of proxying the store, a really elegant middle-ground would be setting up a redirection service similar to what Home Assistant does with my.home-assistant.io (source code/docs here).

With a service like that, the Community App Store (ca.cloudron.io) could simply have an "Install on your Cloudron" button that deep-links to a centralized URL structure.

How it works:

1. The first time a user clicks it, they land on a simple page asking for their private Cloudron dashboard's base URL (e.g., https://my.example.com).
2. This URL is saved securely in the browser's localStorage or a cookie.
3. On all future clicks, the service instantly handles the redirect behind the scenes.

For example, a link pointing to:
https://my-own.cloudron.io/redirect/appstore/io.cloudron.surfer

Would instantly bounce the user straight into their own private dashboard at:
https://my.example.com/#/appstore/io.cloudron.surfer

A massive bonus here is that this doesn't have to be limited to just installing apps.

This redirection service would be a huge win for general documentation and simplifying user support across the entire ecosystem. For instance, official documentation or forum support threads could deep-link users directly to specific settings or user management pages inside their own unique setups.

We could even use it to streamline the onboarding experience right on the main website. For example, the final step of the current installation instructions at https://www.cloudron.io/get.html (which tells users to navigate to their new setup) could instead just feature a clean "Configure your new Cloudron" button using this redirect service.

Since my.cloudron.io is already actively used by the platform, maybe the team could host it on something like my-own.cloudron.io or install.cloudron.io? (Though honestly, it could even just live as a /redirect path right on ca.cloudron.io to keep things dead simple). It feels like a great way to elevate user experience without adding heavy technical debt or blurring the lines on official support.

[robi]

@girish yes.

Much better UX, no copypasta.

[robi]

@fbartels love the ingenuity, but I don't quite like the hijack to an external site.

The App Store is still the primary vector to all app installations. Custom Apps is just an another option, as it is now, without leaving the interface. Just another Cloudron modal that lists the community apps.

Works across desktop and mobile.

[girish]

@fbartels good idea. In fact, we had a plan to implement something like this minus the local storage i.e just forwarding a query parameter from the dashboard and the ca.cloudron.io can forward back. Not sure if it will confuse people to set the "base URL" in a 3rd party page. I think part of the confusion is the word "Cloudron" is used a lot and often in support, we go in circles about explaining different between Cloudron.io login page and Cloudron dashboard login page...

[girish]

@robi Ah ok. No plans for that right now. The versions file, the contents are all completely unvetted. The packages/authors/apps are all not verified. ca.cloudron.io is really just a glorified bookmarking website, it's not providing any other promises. Given the uncurated nature, it would be risky to embed 3rd party content straight into people's dashboards. For example, nsfw screenshots, embedding scammy links in description, things like that.