It could be a manageable app store by the super admin of the cloudron. He could hide the default app store for non technical clients and choose what apps need to be accessible with a customization on the description of these apps. it could be an interface with toggle buttons to activate or deactivate some apps. And you can choose the text you want to show for each app activated. the process to install would be the same. Be careful for me in the back, it is the same app store but it is the front what is different and more compatible with newbies and non tech users.
Certainly, this is another way of seeing and doing things to accomplish this, and it's great ideas as well. That's the reason for such forum and how genius software are created. We have here a crowd of people with amazing backgrounds of all sorts and it's the main reason we've a rich community.
it is a big improvement but it does not seem impossible to do for super @girish ;). Perhaps i don't see all the difficulties it could engage.
Anyway it could be a more comprehensible interface to help the onboarding of new users.
Ah, you're conscious all is possible with @girish right? 😛
@humptydumpty yeah, and I think the vast majority of sites do not and will not get "slash dotted" or get DDoS attacked and anecdotally I've seen WAY more people (including on here) mentioning issues/ problems caused by Cloudflare than people saying "thank good I was using Cloudflare" (I don't think I've ever seen anyone say anything like that)
I think it's a bit like High Availability stuff. As @marcusquinn has I think mentioned elsewhere, most people just don't need it.
And whether or not all/ most of that article I posted is now outdated, it seems obvious to me that everyone using Cloudflare (who in the end are just another investor owned private profit seeking big corporate) contributes to the over centralisation of everything on the web.
Just for info, I also found these bits of their recent SEC return interesting:
We have a history of net losses and may not be able to achieve or sustain profitability in the future.
We have incurred net losses in all periods since we began operations and we may not achieve or maintain profitability in the future. We experienced net losses of $260.3 million, $119.4 million, and $105.8 million for the years ended December 31, 2021, 2020, and 2019, respectively, and as of December 31, 2021, we had an accumulated deficit of $680.8 million. Because the markets for our products are rapidly evolving, it is difficult for us to predict our future results of operations. We expect our operating expenses to increase over the next several years as we continue to hire additional personnel, expand our operations and infrastructure both domestically and internationally, and continue to develop our products. In addition to the expected costs to grow our business, we also are incurring significant additional legal, accounting, and other expenses as a public company, as described in greater detail in the risk factors below. If we fail to increase our revenue to offset the increases in our operating expenses, we may not achieve or sustain profitability in the future.
We have experienced rapid revenue growth, which may not be indicative of our future performance.
We have experienced rapid revenue growth in recent periods, with revenue of $656.4 million, $431.1 million, and $287.0 million for the years ended December 31, 2021, 2020, and 2019, respectively. You should not consider our recent growth in revenue as indicative of our future performance. In particular, our revenue growth rates may slow or decline in the future and may not be sufficient to achieve and sustain profitability, as we also expect our costs to increase in future periods. We believe that historical comparisons of our revenue may not be meaningful and should not be relied upon as an indication of future performance. Accordingly, you should not rely on our revenue and other growth for any prior quarter or year as an indication of our future revenue or revenue growth.
will not allow for adding essentially multiple DNS provider for the same domain
Just to be clear, I'm not looking to store multiple DNS credentials, if I switch it in Cloudron to Vultr from DigitalOcean, I'd assume or expect Cloudron to clear out the old credentials/API keys, so it definitely doesn't need to retain two or more at any given time for a single domain. Hopefully that clarifies that part. Definitely no need to go down the rabbit hole of refactoring, haha.
if there would be an option to not resolve DNS records from the Cloudron side, one could change the DNS backend, then hit re-sync DNS in the Cloudron dashboard, then wait for the new nameservers to have all records in-sync and then switch the nameservers for the domain itself.
That's basically what's being asked here... to remove the requirement to double-check the nameservers in the first place before being able to save the API keys on the domain. I understand why Cloudron does it, it's to help avoid DNS propagation issues, however at the end of the day, Cloudron works as a script to populate the DNS records in any provider we give it access to, so it should not be restricted to only doing so if the nameservers are configured correctly. That limitation that exists currently prevents admins from having Cloudron setup the DNS records in the new location first which of course is best practice before switching the nameservers at the domain level, you don't want to be doing it afterwards. 😉 I think a good compromise if Cloudron team feels it's necessary to still check for nameserver pointers, is to warn but allow a user to move past it to freely have Cloudron setup the DNS records where we provide access regardless of nameservers.
Does the above make sense? I can clarify if needed. Basically just hoping that limitation can be removed in the product as it's impeding what I'd think are some important tasks to be able to do before changing nameservers on a domain.
I will investigate more tomorrow. Maybe we can fix up mail data timestamps post restoring.
Thanks Girish! Definitely seems like this is a low priority issue given that nobody else using Cloudron has run into this yet, but its also likely something that will come up again as Cloudron grows with more users, and would be great to see that handled in Cloudron automatically, making things easier for the admin users. 🙂
I teste FileRun in a LAMP app (after reading @scooke reply here) and it does exactly what I need without all the added bloat and unpolished UI of Nextcloud.
✔ It sorts pictures by date taken
✔ Has a better UI than NextCloud (personal opinion)
✔ It is a lot faster in previewing images
✔ Works with the Nextcloud desktop and Android client (or any other app that supports webdav)
✔ Can organize photos in albums and collections (I am not really interested in this, but it's a nice to have)
I hope that it will officially come to Cloudron at some point.
@robi Good point ... I think it's this way because one way to expand boxdata/appdata/platformdata is using symlinks. Then there's volumes , backups. So, it was easier to filter out by known filesystems.