I was thinking about the idea that private sites don't really need a "vanity" (for want of a better word) subdomain name that matches their name.
This lead to the idea of removing the tight coupling between a site's subdomain and its name.
Considerations:
For a private site, the domain name isn't very important. So we could generate some id perhaps with the username included and use that. This leaves the "nice" subdomain available for someone who does want a public site.
For publishing content, it might be interesting to be able to route a site to a particular subdomain name where the site appears read only, but have it also available at a different domain name requiring authentication for authoring. This would also allow version control, e.g. if you wanted to release a new version of your site you could draft it in private then route it to your public domain name to release it.
There are some non-trivial workflows to consider, e.g. if you own a subdomain, is it your forever? Could the same site be served on multiple subdomains? If so would we have a preferred subdomain to appear in the hub? Would domain squatting or typo-squatting be a problem? What if you switch a site from public to private, does it keep its subdomain. Etc etc.
Note that a little over 60% of sites are private, so that's a lot of nice subdomains being "used up" for private sites.
I was thinking about the idea that private sites don't really need a "vanity" (for want of a better word) subdomain name that matches their name.
This lead to the idea of removing the tight coupling between a site's subdomain and its name.
Considerations:
Note that a little over 60% of sites are private, so that's a lot of nice subdomains being "used up" for private sites.