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.
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.
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.)
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.
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.
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.
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.