Possible to remove the "my" subdomain for the dashboard

[nebulon]

You can find more information on that at https://docs.cloudron.io/domains/#dashboard-domain

Essentially so far requests to change that subdomain weren't many and since it is hard-coded in many places, we didn't spend time on this so far.

[Lonkle]

@nebulon Is it in the open source section of cloudron code for me to take a stab at it? I've been intimidated to try to edit Cloudron itself for merge requests and this seems like a simple (but needing to be thorough) URL / string replace which might allow me to start small before moving up to the network level - but still needing to read over all the code so I don't miss anything.

[Lonkle]

My use case for this is that so many apps are using "my" subdomains this days that my browser suggestions go ballistic when 9 times out of 10 I'm going to my Cloudron server.

[marcusquinn]

I kinda like having it follow the my. convention. Easier to remember than all the SaaS variants like console., dashboard., cloud., hub., accounts. guesswork.

I you haven't already tried, I'm finding Vivaldi browser much nicer for personalising all these kinds of productivity tweaks.

[scooke]

@marcusquinn hear hear! I too like the "my" convention. The other examples you listed too much emphasize that its a dashboard/console/hub on their service. When it comes to Cloudron, the "my" is a nice reminder that this is in fact mine. It's my data, my usage.

I too have a few other sites starting with my.* but I use my Cloudron so much that now it is the first my.* that autocompletes. Stick with it @Lonk! Eventually your Cloudron will also pop up first.

[Lonkle]

@scooke I agree, it will. But for me it's more of a symbolic thing. I bought a domain just for cloudron and I just really want cloudron to reside exactly at that domain. It's such a small thing, but I'm willing to put the work in if the main developer's don't mind making it optional? I have to dive into the base Cloudron code (both the open and closed source sections) to finish my OpenVPN Client app anyway.

[marcusquinn]

@Lonk Not tried but maybe a CNAME DNS record would do it?

[Lonkle]

Nice idea, I tried it but you can't make a CNAME on the root of a domain's DNS. Just my luck.

[marcusquinn]

@Lonk Ahh, true, I was thinking backwards. www. ? Or just stay in the my. club that likely will cause less support issues

[Lonkle]

@marcusquinn For now, I will - but if @nebulon or @girish give me the go ahead to let me find and make the “my” sub-domain optional (not hardcoded) in their base source (I’m getting used to editing their box source now). I’m going to do it. Nothing better than a clean domain for what I want to eventually make my browser startup page / dashboard.

[girish]

I think the my subdomain is deeply embedded all throughout the product. While it's possible to change it, it's a lot of work and not worth the time (for us, anyway). We have to fix the dashboard, docs, support, 1-click image instructions, tutorial, cli tool. Everywhere it assumes the my convention.

[Lonkle]

@girish Oh, I wouldn't try to do it until I understand your codebase much much better first. But maybe next year, in 2021, would you mind if I jumped in and made it optional (removing all the hardcoding)?

Making it optional means keeping the default as "my" so no need to change the docs (much at least).

[girish]

@Lonk Not about the code as such, there's just a lot of mindshare/support associated with changing 'my'. Last time we looked into this was in the previous release and we identified that people mostly complained because the mail server location was also 'my'. So, we made that customizable in 5.6 (https://git.cloudron.io/cloudron/box/-/issues/672).

That said, if there's interest, we can revisit this later, not a problem.

[Lonkle]

I gotcha, I'll post again about it next year to see if there's interest.

It's cool that the mail server's "my" was made optional. I'm glad you're open to revisiting this later because, maybe I'll have gotten so use to it by then that I won't even request it again.