&quot;Custom Domain&quot; integration

Tue, 31 Jul 2018 21:18:51 +0000

I haven't looked enough under the hood - but, besides SSL issues, what are the most significant hurdles to user customization the URL that points to their pages/content.  I'm thinking something like the way web servers allow "virtual hosting" of multiple domains on the same IP address.  How hard would it be to allow the same hubzilla instance (or a subsection of a single instance) to be referred to by a custom domain (for example, optimally the ability to have everything related to my user could be under zot.mycustomdomain.com/...  instead of hub.webgoeslocal/xxx/dm42/xxx or even www.mycustomdomain.com is an alias for hub.webgoeslocal.net/page/dm42/xxx)?

I'm thinking like "Wordpress.com" allows you to bring a custom domain name and use it to connect to your Wordpress site, what problems would be involved in allowing (1) just a straight "alias" for the domain or, even better, (2) allowing for instance a custom domain for your own WIKI or Webpages or even shopping cart?

I'm mostly looking for a beginning list of "these things are going to be the toughest to overcome" or "these are the things someone trying to implement such a change probably wouldn't think of/consider."

I'm NOT at this point thinking of having customizable channel identities (the same channel referred to using different domains - kind of like clones, but without them being on separate servers) unless it's easier than I'm imagining.  As a first pass, I think making it work with "public only" content - maybe even only aliasing certain modules would be easiest - though the goal would be to allow people to magic_auth into the aliased instance to access protected content while retaining the custom url.

Like it or not, most people are not sophisticated enough to realize that the lack of a recognizable domain name in the URL bar means absolutely nothing about the "realness" of the entity supposedly running the web site.  Most people using the internet still think that it takes significant resources to just have your own name show up in the address bar and use it as a mark of legitimacy of the site.   That hold is slackening slightly, but I don't think it will ever go away entirely.

Ultimately, i think especially commercial adoption / use of Hubzilla would be aided significantly by such a mechanism.

show all 5 Comments

Tue, 31 Jul 2018 23:18:07 +0000

Decentralised communication brings with it a number of unique issues. One of these is that host aliases turn every lookup of a specific identity into an exponential problem.

This software stack attempts to minimise this by forcing one canonical URL for every server. You can arrive at the site via xyz.example.com but internally all links are absolute and are re-written to example.com.

This is something we've wanted to do for years in order to (for instance) support TOR. I've investigated a number of different implementation ideas. All require a great deal of work. In the simplest form App::get_baseurl() would not look in storage to obtain the canonical URL for the site. In order for identities to work cleanly, we'd need a host alias mapping table and provide a list of aliases in the Zotfinger packet. This way other sites could discover aliases and collapse all the various equivalent URLs into one and use that one URL for all transmissions. Otherwise you need to send messages to every alias, which is an exponential waste of effort. You would still need hubloc records for every identity/host-alias pair to verify incoming nomadic identities.

Wed, 01 Aug 2018 00:14:06 +0000

If we assume only PUBLIC content to be accessible in this way and thereby remove the identity issues, would it be a reasonable thing to hope to map paths in the webpages tree to custom domains?

Wed, 01 Aug 2018 00:29:00 +0000

I'm actually OK if identities are not aliasable. I just want to be able to, for example, point a web browser to https://mycustomdain.com and have it show content that would normally show up under https://myhub.com/pages/myuser/subweb or something similar. Being able to authorize users into https://mycustomdomain.com would be a major bonus and a highly desired feature. But I'm not sure there is an a real need to be able to alias me@mycustomdain.com to me@myhub.com. That would be NICE, but is beyond what I think of as "essential" for the purposes I'm contemplating.

Wed, 01 Aug 2018 00:58:14 +0000

You can do all of this now, but it's more a matter of Apache and mod-rewrite configuration (or nginx conf) and doesn't really affect Hubzilla itself. In any event, if you think you can make something work, go for it.

Wed, 01 Aug 2018 01:10:04 +0000

Nice! An app written right!!!! I probably won't have time to play right away, but nginx rewrites (actually openresty with LUA accessing MySQL) was one of the vectors I was planning to try. IMHO, that's the "right" way to handle it anyway. It's just that other apps I've worked with did funkiness internally and relied on the Host: header in weird ways to make it impossible.

When I can I'll play/try and report.