What should be the URL pattern for communities

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.

6 Likes

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.

5 Likes

Yeah, I’d suggest that we have a central login (codidact.org/auth), which redirects back after successful login to the proper page again.

4 Likes

I highly recommend that everything authentication, certificate and whatnot based is only tied to codidact.org

1 Like

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.

1 Like

Is that written down somewhere?

Hereby. :slight_smile:

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.

2 Likes

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

2 Likes

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 :slight_smile:

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.

6 Likes

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.

5 Likes

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.

3 Likes

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?

2 Likes

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:

11 Likes

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?

1 Like