@MooCloud_Matt said in tmpfs support in the manifest:

@Lonk
you mean for a private docker registry ?

Though I could do that yes, I was speaking more in terms to an actual alternative App Store, private or public registries wouldn’t matter. I’d probably originally make it only public registries at first.

Like, I’ve been wanting to create Dot the Repair Bot Cloudron app but it’s more of a Cloudron add-on and probably doesn’t belong in the official store (maybe, not sure). But if it didn’t and I still wanted it to be accessible - I could build an alternative App Store with the docker add-on and put apps on there.

Orrrr, the official App Store could gain sources in which case I would just host a JSON file on BackBlaze and give people the source’s URL to use and it would pop up in the store as a third party app.

It would make beta testing apps with people wildly easier if the Cloudron App Store allowed for more “app sources” than just its hard coded internal source that @girish and @nebulon maintain alone.

Thanks @girish Can't hardly expect it 😉

@MooCloud_Matt See https://docs.cloudron.io/networking/#whitelist-ports on how to whitelist an incoming port.

On mouseover, you already have the URI popup at the top, so on a long description you could have that popup on the flip side on the bottom.

With this last thing, I know have the perfect flow for developing Cloudron apps. Thanks again for telling me about it @nebulon!

I upvoted. I agree the click targets could be a little more intuitive. Maybe even customizable (why I made my other post).

@jdaviescoates said in Usability - Can't find current Cloudron version on my.domain.tld:

But, I still like my preferred solution here:
https://forum.cloudron.io/post/15541
Would keep everyone happy, no? (and also has 4 upvotes )

Five now, we already have a "Footer" section to change the footer text, a checkbox for "Add version number" isn't too crazy I think for those of us that liked it (I did personally).

This is easier with Yugabyte DB.

@girish kinda makes sense when you explain that. Maybe start with what I said above, then we can see how that website UX can feel.

Personally, I'm migrating away from GMail, and wouldn't recommend it, although I appreciate it's difficult to cut those ties for some.

Another possible solution: would be to forward to any other email service that does support POP3 but doesn't have spam filtering. That way, you're not sending email to GMail, it's pulling and filtering. Appreciate that a 3 mailserver setup is odd though, but then so is GMail.

I think it's worth just having a POP3 post in Feature Requests though, purely as a way to allow for any other 3rd party email someone wanted to do this with. I can see privacy advantages in POP3 as well, if one didn't want emails stored on their Cloudron and just locally. I wouldn't like to see POP3 ignored as without advantage, when if privacy is a concern, that could be a legitimate use-case.

I'll keep living with the "my" subdomain for now. 😂

@robi I haven't looked into that since I'm literally the only person that uses my own apps (I'm participating in this thread because I care about the Cloudron Communities Growth, not because the feature interests me). So, thank you for the offer, but I think I grasp the idea. But if anyone else needs it, let robi know guys! ☺️

Since @girish has setup the ci pipeline in Gitlab for our docs to push into a surfer instance, such changes are so easy now!

So https://docs.cloudron.io/custom-apps/manifest/#configurepath is up.

@girish There's was a lot of times I didn't want to uninstall to re-install (just re-start with some box changes), but when "restarting" them I had to wait for them to finally "Not Respond" at certain points to restart my test of it connecting apps. Obviously because I was working in box out of necessity, my specific situation was a little weird. 😅

I also experienced this and I am v happy it's fixed. You guys are the best!

I'm with @nebulon, I see this as difficult to support, harder to code for - and more user friction. I usually never support more user friction unless it's dire. I think configuring after installation is more than acceptable. It's not like we can't write scripts using their API to macro your suggestion too, but I digress. 😂

@nebulon nice work, it will do!

Thank you kindly.

@girish domain expiry is more of a calendaring function IMO

but a whois query at domain setup could get you that date which Cloudron could remember and prompt during that month via notification.