Cloudron Forum

It seems gitea made a release tag, deleted it and then recreated the release tag. This caused a sha mismatch. I made renovate skip over that error - https://git.cloudron.io/packages/gitea-app/-/merge_requests/47

@dsp76 Good point about the matuc example. But I think URL based protection is more complicated because we will need help from the apps. For example, it will require all of mautic admin and it's assets to be designed to be served from under a specific subpath. I haven't really investigated how friendly apps are in this regard but most likely we will have to handle this package by package (in a future release).

@paradoxbound we are getting there with Cloudron 10. Unfortunately, there are no plans to make another release before that. Please hold on...

@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.

@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...

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

@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.

@timconsidine done, it's 25 now .

@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 done, added a basic filter and app count as well

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.

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.

To add, any one can submit to the community app store and submissions are not vetted by the Cloudron team or "managed" by us. We are just providing a way for the community to discover each other's apps. That's about it. We don't want to be part of the submission flow. We think that would defeat the purpose of allowing people to list and install any app they see fit.

I think Go apps don't want to work with non-TLS mail servers (a bad decision, but who has energy to fight all this)

@fbartels yeah, ntfy "hangs". If you wait for a long time, you will see a 503 .

@timconsidine there's a big discussion here - https://github.com/the-djmaze/snappymail/issues/1911

@jdaviescoates said:

But given @girish is one of Dovecot's top contributors

Not sure where you learnt that but I haven't contributed a single change to Dovecot. May be you mistook my contributions to Haraka.

I will have to investigate the exact issue though. Unfortunately, both roundcube and (now dead) snappymail, are both not great at searching .

@simon yeah, that makes sense. I think I will just cap it for all instances to 4.

@chilipp @fbartels this should be fixed now. Issue was that ntfy is a Go app and it requires the mail configuration to have a valid certificate to send emails.

I also noticed that we don't require login by default. I enabled that as well in the config.

The new update should fix the problem.