Sure, it’s technically possible either way. That has nothing to do with the address. But, conceptually, it’s a big difference. Different subdomains feel like a different thing in a way that different paths within a single domain do not.
Yeah that was my reason for adding it. For some reason I didn’t explicitly suggested a c, though.
That precisely. Using the URL path to specify community introduces the conflict problem; separate domains doesn’t.
What we should consider, which has only just struck me, is login/authentication. This is a problem that Stack Exchange had as well. If, as is normal, we do authentication with a session cookie, we will have to be careful to set it on codidact.com
, not on sitename.codidact.com
, otherwise we’ll lose access to it on a different community (and thus lose access to the account details, whether or not the user is a member of that particular community). We’ll also have to be careful not to split our instances over multiple 2LDs (as in stackoverflow.com
and superuser.com
) - otherwise, again, we lose the cookies and have to start doing funky things to maintain authentication.
Yeah, I’d suggest that we have a central login (codidact.org/auth), which redirects back after successful login to the proper page again.
I highly recommend that everything authentication, certificate and whatnot based is only tied to codidact.org
AFAIK, the .ORG domain is for stuff about our project, team and organization, whereas the instance is on .COM (for COMmunity). Therefore we’ll need to put it on codidact.com. But otherwise I agree.
Is that written down somewhere?
Hereby.
It has been somehow applied, though, by having a writing community under writing.codidact.com and our design framework under design.codidact.org. I’ll add it to the Wiki, though. Good point.
And just to clarify: The structure will apply to any instance (unless code is changed by another instance) - e.g., “session login at instancename.tld/auth”. But the choice of domain name is separate for each instance and the founders of Codidact have decided (and I agree) to use .org for the software development site and .com for the actual community sites. But another instance might use somethingelse.org and that’s OK.
I think only the navigation paths should be to the right, and they should all work the same for all instances.
For the address of the instance and major sub-section of it, like Meta or Wiki or some other big site, use the left sub-domain part of the url.
So like:
anyinstance.codidact.com/questions/123
anyinstance.codidact.com/questions/123/125 – anchor link (scrolls down to post when page loads) to an answer with post ID125
anyinstance.codidact.com/post/125 – same result as previous link
anyinstance.codidact.com/users/54321
anyinstance.codidact.com/api
anyinstance.codidact.com/about
anyinstance.codidact.com/help/asking-questions
and
wiki.anyinstance.codidact.com/Main
meta.anyinstance.codidact.com/tags/bug
If someone wants to host an instance on their own domain, replace the anyinstance.codidact.com
with ownsite.tld
:
ownsite.tld/posts/234
meta.ownsite.tld/moderators
wiki.ownsite.tld/Badges
Also I don’t know about chat having its own subdomain on meta as it is on SE, I think it should just be straight up a single chat link for all sub-sites, and then you should be able to filter chat rooms on the page.
like:
anyinstance.codidact.com/chat/rooms/5678
ownsite.tld/chat/rooms/5678
or
chat.anyinstance.codidact.com/rooms/5678
chat.ownsite.tld/rooms/5678
instead of
chat.meta.anyinstance.codidact.com/rooms/5678
chat.meta.ownsite.tld/rooms/5678
I’m torn between the two options, honestly
A separate chat system is not in our plans right now. We are going to do comments better, which will fill some of the per-post need. For now, if communities want a chat server they’ll probably need to set up their own. (There’s always Discord…) We need to focus on the core platform first.
There’s actually a good reason to put the wiki.
/ meta.
sections further right in the domain. That allows you to use just a few wildcard certificates for SSL, rather than needing a whole elaborate infrastructure to automatically spin up and maintain individual certificates for each site and its wiki and meta subdomains. Switching this over gave SE a major hassle a few years back; we should learn from that and do it right the first time.
Modern browsers do that for any part of the URL. If the community name is not too common (e.g. an community about APIs that has api as identifier) that will not be an issue.
Also, things “within” a site belong to the right; meta or wiki or whatever isn’t a whole separate site but a sub-part, so it shouldn’t have its own URL. (Yes this is a change from how SE handles meta; we’re not going to have a whole separate site but, rather, a tab or something for those questions.)
Thanks. I did not realize that.
There is one more thing, if the subdomain schema is enabled a user that visits e.g. codidact.com/community/foo he should be redirected to foo.codidact.com because that just looks nicer in the browser, that is, in my opinion.
If wiki.foo.codidact.com or something like that were allowed, doing this redirect would require some extra work implementing that.
Do we commit to that?
Correct. And that can easily happen if an “Area 51 site” gets out of beta and is now assigned a subdomain. The Google-cached information will have the old format but the site should automatically redirect to the subdomain format. Which is all pretty standard stuff. No big deal.
I believe we have consensus on the following. If there are no new objections in the next 48 hours, we will proceed with this:
-
We support the domain/community/community-name pattern, e.g. codidact.com/community/writing. (“community” and other strings are configured to support internationalization.)
-
We enable an instance to map that to subdomains, e.g. writing.codidact.com.
-
The instance we host will do that mapping; we are committing to subdomains for our communities. (One layer only, not something.communityname.codidact.com.)
-
Other pages, e.g. login, admin, user, tag, go to the right in either scheme: writing.codidact.com/user/123 or codidact.com/community/writing/user/123. This also applies to instance-wide pages, e.g. codidact.com/admin.
-
Category names such as meta, blog, or wiki go to the right under a “category” layer, e.g. writing.codidact.com/category/meta. (This differs from the above proposal but reduces the risk from arbitrary category names colliding with baked-in elements.)
-
We have not yet specified the full interface for URLs, i.e. what things can go to the right.
One advantage of having metas be separate sites is that there’s absolutely no confusing which site/category you’re on when looking at tags, review queues, etc.
I know we haven’t even decided yet what “metas” will look like, but I wouldn’t want to rule out a separate site/domain for them.
I also don’t understand why wikis are being considered, must have missed that discussion, but that’s also not what this topic is about.
I think I’m the one who introduced “wiki”, and I was addressing the idea of canonical posts. “Canonical post” is insider-speak (probably SE-insider-speak, in particular).
What are the properties of meta that make a separate site attractive? Distinctive look can be done with category-specific styling. Vote segregation (so that if we have rep we don’t have to give it for meta posts too) can be done by restricting by category. Filtering your own contributions (so you can see just your meta posts etc) can be done by applying category filters to the user profile page instead of having a whole separate user profile. What concerns have I missed?