What should be the URL pattern for communities

One instance of Codidact will support hosting multiple communities. My question is, how they should be separated in the URL.

I can think of two ways:

  • Subdomains (<community>.codidact.com1)
    This has the advantage of having a clear URL for each community and is IMO more user-friendly, when typed in an address bar with autocomplete. It implies more separation or independence between communities in comparison with the other method. This is how Stack Exchange does it.
    It has the disadvantage, that we’ll need to do some strange DNS-stuff IIRC.
  • URL part (codidact.com/X/<community>, where X is any letter)
    This has the advantage of having one domain name only. It’s probably easier to do in DNS and some sites (Reddit) use this, so it isn’t too bad for user experience probably. The communities seem more connected IMO. This is probably easier to set up for third-party hosters of Codidact.

I would personally prefer the first way for us and the second for third-party uses, however I am not sure, whether it is possible to make this configurable.

What do you think?

1 Remember: The .COM is for COMmunity!


Personally prefer your second proposal,

codidact.com/X/Writing, for example.

In my opinion, it’s more easily readable, and as a user, lets me simply double click the end bit and replace it with the correct URL for the community I want to visit. Your point about it being similar to Reddit is a plus in my eyes as well; it’s more familiar to newer users!

The point you presented of ending the url with .COM “.COM is for COMmunity!” holds weight, however the second option gives us a chance to set the domain a bit apart from Stack Exchange. Plus, it avoids DNS hackiness, if that’s a problem.

Subdomains are not “totally trivial” but they are “relatively easy”. It depends on the web server, hosting support (e.g., my favorite hosting company, ICDSoft, makes setting up subdomains, with Let’s Encrypt https, absolutely trivial to do, but the catch is that they don’t provide the flexibility to support some of the other stuff we need to do to actually run the software) and other factors. But it is not hard. Actually, the hardest part is probably making sure that the https certificate works correctly.

On the other hand, “URL part” is something that can be baked into the software. In other words, anyone standing up their own instance of Codidact could do that with only the one initial DNS setting for the main domain, and only one certificate since there are no subdomains involved.

Set up the software to handle URL part directly and to include whatever is necessary (which should not be much) for Subdomains. And then the last bit of Subdomains is an exercise for the reader.

IMHO, advantage for the ordinary user is subdomains. With subdomains, once you’ve visited once and your browser “knows” about it, you can typically (browser, history, etc. dependent) just jump to the top and start typing the name of your preferred community - DIY, Writing, etc. and have the whole thing pop up for you. Actually, to a lesser degree that will work with URL part, but I think it is a little more intuitive and (possibly) reliable if it is the subdomain name.


One further advantage of the subdomain is, that the existing Writing community (using a temporary software solution) has that format (writing.codidact.com).

Also the TLD thing wasn’t meant as an argument for or against any of these options, but as a justification for COM over ORG or so.


codidact.com/X/(community)” seems very counter-intuitive to me because of the “X”. Why does there need to be anything there?

I favor subdomains ((community).codidact.com) for usability, but could live with codidact.com/(community). If I’m not going to get my favorite community in just a couple keystrokes in the URL bar, though, I at least don’t want any more friction than needs to be there (the “X” in this case).

Writing is already, as noted, using the subdomain; it’d be nice to not break that if we don’t have to.


I don’t know much about web infrastructure, but I’d imagine that having each site be a subdomain would make it easier to scale resources etc. It would also isolate each site so if something happened to one the others might be protected from going down.

Agreed. What’s the point of the extraneous level?

1 Like

Actually, only minimally. At the level of "assign a server to a (sub)domain, yes that can work. But there are other ways - which is how Google, Amazon, etc. have millions (billions?) of users all going to the exact same domains. Scaling can be done a bunch of different ways.

Actually, it wouldn’t. Yes, right now www.codidact.org goes to one server, forum.codidact.org to another, etc. But you can have multiple subdomains (or multiple domains including all their subdomains) all going to one server and be a single point of failure. You can also have multiple servers - e.g., one for each subdomain - but if they share a database then that becomes a single point of failure - which is why there are redundant databases available. Again, lots of ways to do this.

I know that you can have multiple domains per server and multiple servers per domain, but if communities were subfolders, even with load balancing, they’re still closely tied together.

Subdomains gives flexibility. They could share servers, they could be entirely separate systems.

For those who think subfolders are good, what are the advantages? Anything else than having only one domain? (Which I don’t think is really much of an advantage.)

1 Like

You can also proxy requests to a load balancer using subfolders like you would a subdomain, and it avoids subdomain complexity.

1 Like

Not much to choose technically either way - in one case you set community context from the Host header, in the other you set it from the URL path. DNS isn’t too difficult to set up for this - just point everything at one server (or one of the alternatives that various people have suggested here). If this was Rails, I’d be able to tell you definitively that it’s possible to make it configurable which one is used; since this isn’t Rails, I’ll have to leave that to folks more versed in the ecosystem. It’s probably doable.

The only valid reason I can think of is to avoid naming conflicts (which is exactly what Reddit does): if we want to include instance-level admin reporting, for example, that might live at codidact.com/reports - but what if we have a community that wants to be called “Reports”? And that might not just be one URL - there might be /reports, /settings, /admin, /setup, and various other instance-level functionality that should have a top-level path, which takes up some naming space. It’s not a huge problem, but the added /X/ (or probably /c/ for community) does free up those names again.


Perhaps all admin functionality could live at (and under) “codidact.com/codidact-admin/”, leaving the top-level path clear for community names.

Those potential conflicts are only a problem if we use the codidact.com/site-name approach. This sounds like another argument for site-name.codidact.com; that way /admin applies to either a site or the network depending on the domain, but you never have to worry about a conflict with a site name or inserting extra stuff just to add padding.


Plus the subdomain method also allows for:


In fact, maybe the solution is to have x = ‘community’ (the literal string community in this case). That way you could have, using abc as a community name:

and then the only “prohibited” community name would be “community” itself. And of course that would be a string stored somewhere so a Spanish instance could use:


Only an instance that wants to (and has the DNS ability to) setup subdomains would need to bother. But even if an instance does use subdomains, the domain.tld/community/communityname configuration should still work.

1 Like

My vote, being used to how both Reddit and SE do it, would be for


Another possibility, reddit makes the first example redirect to the second.



Except that’s awfully long (especially with all the extended URLs) compared to communityname.codidact.com. Why make extra work for users?

For Stack Exchange, I can type “wr” into my browser and auto-complete to Writing.SE, or “j” and auto-complete to Mi Yodeya (judaism.SE), or a couple others. With this format that’s not going to work. What is the offsetting good thing that makes losing that worthwhile?

If this is something that we can let instances decide on (i.e. if we can make both work), then I’m arguing for our instance. If it has to be one or the other, I prefer this barring technical reasons to the contrary.


I am 100% certain that with our instance we can set up subdomains. ArtOfCode and others have the expertise to do it and it really is not a “big” deal.

However, sometimes (and I have done this kind of thing occasionally so I am aware of at least some of the potential complications) it gets messy due to DNS issues, server (Apache, etc.) issues, certificate problems, etc.

What I am trying to say is that the software we are developing should include domain.tld/X/communityname/stuff URLs (where for us domain.tld = codidact.com, X = community (or something else - I just don’t list ‘site’ as that is confusing - a single word that is common to the entire instance) and communityname = writing or diy or whatever.

For any instance, definitely including the primary instance we are planning, that has the ability to set up subdomains, it should be relatively easy to map everything so that:

  • communityname.domain.tld/stuff
    maps to
  • domain.tld/X/communityname/stuff

The end result is:

  • we get the shorter and clearer subdomain configuration
  • any new instance without subdomains set up or for testing purposes or whatever, only a single functioning domain (which could be a default domain.tld or www.domain.tld or somefancysubdomain.domain.tld) would work just fine with no extra configuration needed.

I feel like this is more than a naming discussion. It really sets up the expectation for how independent each site is. If trust levels, reputation, badges, etc., are shared across all of the topic-focused communities, then it should be example.com/topic. If, instead, each is primarily an independent site, then topic.example.com.

@mattdm I disagree. Everything configurable-per-community - name of community, Trust Level/Privilege/etc. configuration, naming of various terms, rate limits for new users, available features (e.g., blog, canonical, discussion, etc.) - all of that will be set in the database and is totally separate from whether a particular instance uses subdomains or not. The communities are just as independent with either URL schema.

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.