Subdomains Are Good

Before Victor and I founded FediHost, we were of course hosting our own Fediverse services and in my case, I think I made an early mistake that you might might be able to learn from.

Clarity First

For me in particular, I’ve always preferred a clean, tidy approach to messaging and how I communicate. If you have read my writing. You will know. That I like. Very. Short. Sentences.

Take the name FediHost. I wanted it to be as short as possible and obvious about what it does. The same principle applies to domains. I like short, easy domains. Something clear and intuitive, something you can give to a non-technical person without overwhelming them with a string of words that make their eyes well with tears. It’s simply how I like to communicate.

The Universal Handle Dream

So when I was setting up a Mastodon instance, I wanted my handle to be @paige@canadiancivil.com. Not @paige@mastodon.canadiancivil.com.

More broadly, I’ve always wanted the Fediverse to support a kind of universal master handle. In that ideal world, @paige@canadiancivil.com would be my PeerTube handle, my Mastodon handle, and the handle for whatever services come next.

How the Fediverse Actually Works

But no matter how much I wish for that and whine and complain to Evan and all the fediverse service developers, this just isn’t how the Fediverse currently works. By design, the Fediverse is made up of separate services "keyed" to separate domains.

And over time, I’ve come to accept that this is just the way it works. Fighting against it specifically fighting against subdomains is a battle which I am raising the white flag on.

The Website Problem

The first issue is the root domain itself. When someone visits a domain, they expect to see a website. A website is still the primary thing a domain represents it’s the professional business card of the internet.

If you put something else on the root domain, the obvious question becomes: where does the website go? Like great, you put your mastodon instance on the prime real estate, but now where is your website?

A Case Study: NWT.Social

For example my friend Jeremy started nwt.social where he is building an online co-op have made this tradeoff. The good side is that when you're a member of the co-op you have an nice, tight handle of @name@nwt.social on mastodon, but there is also a downside.

When you search for nwt.social the first result is usually this instance, you click it and will land on a Mastodon instance and the default feed. If you want to learn about the co-op you have to look around the instance to find something linking to their website because Mastodon doesn't make it super easy to add an obvious "Go To Our Actual Website" custom links bar at the top of each page.

I think the expectation that a domain name resolves in a "Homepage", hasn’t gone away, and I don’t think it will soon.

Root Domain Portal

I think the cleanest solution is to treat the root domain and website as a portal. You have your normal site on the root domain, and then links out to Mastodon, PeerTube, and whatever else. This already mirrors how people find each other online. We google a name plus a service "paige saunders mastodon", "bald dummy peertube" and we find the account.

In that context, the fact that a service lives on a subdomain if you lean in and read the domain closely really isn’t a big deal.

WebFinger and Painting Yourself Into a Corner

This is when bald dummy tried to get around all of this using WebFingers, and that’s where things really started to feel boxed in.

WebFingers? These let you use a little magic on a server so that you can have your fediverse handle show as one things (eg @paige@canadiancivil.com) even though it's actually located elsewhere (eg @paige@masto.canadiancivil.com). This lets a website appear as normal at that domain and you get a shorter handle on the fediverse.

Yes, you can keep a website on the root domain, but you effectively prevent yourself from running other Fediverse services there anyway.

Only when I went to setup a ghost blog as the website which has Activity Pub integration did I realize I had made a mistake.

Changing Your Daily Driver

It makes sense that if anything you would put the account you use the most on the root domain, but what if that changes?

Over time, I’ve also realized that I’m probably more of a Threadiverse person. I expect I’ll eventually use the first Threadiverse microblogging service we deploy with FediHost. If piefed adds microblogging support, I can almost guarantee I'll move.

The problem is that paige@canadiancivil.com is currently my Mastodon account. I’ve effectively locked the most valuable Fediverse handle I have to one service. Anyone who’s spent time on the Fediverse knows that services change. Migrations happen. Software evolves. Locking a canonical handle to one platform means the best case scenario is that solid move commands are implemented by both the old and new service (this is rare). This would let me migrate it to a new subdomain paige@piefed.canadiancivil.com location, but at this point it is only a hypothetical in the case of Piefed.

In the case of nwt.social, pretty quickly after Jeremy started it I realized the preference for people in the far north of Canada is far more reddit than twitter. Maybe he would prefer a threadiverse service? Unfortunately he's now stuck with Mastodon on the easiest to remember premium real estate of the root domain.

DNS and Hosting Annoyances

There’s also a practical hosting issue. If you end up using WebFingers to get around some of these issues so your root domain can show a website to visitors while keeping your fediverse service on a subdomain there needs special handling to support it.

That often means self-hosting your website, which may not be what you want. If you’re using a hosted platform, you’re dependent on whether it supports the necessary redirects and configuration. Many don’t.

The end result is that you again limit yourself or spending more time fiddling around with things.

Once we started FediHost, I got more and more into the idea of using subdomains as people using our services started to run into problems. One problem that very frequently happens is a bit odd and funny: a lot of services don’t actually support ALIAS DNS entries for root domains. We get a support ticket every couple of weeks related to this issue.

If people really want to use the root domain they sometimes have to go setup a separate DNS host to handle it. That's not tidy.

The easiest solution is to use CNAMEs, but CNAMEs only work on subdomains. As a result, people have had to change DNS providers, which can be a steep and difficult process for those using managed hosting services.

Why Subdomains Make Sense

I've realized that subdomains just make a lot of sense. They don’t have to be big or ugly. Originally, I imagined something like mastodon.mywebsite.com, but you can use just one letter, like m.mywebsite.com, or something shorter like masto.mywebsite.com That’s actually not unattractive and it's helpful to know when you look at a handle what service it actually is.

Some suggest buying different domains for each Fediverse service yourwebsite.video and yourwebsite.social but that ends up being expensive and effectively you're making these root domains behave like subdomains anyway. In fact subdomains are better because they group everything under one banner. Your root domain delineates your online territory and makes it clear that the subdomains beneath it are all part of your property.

Subdomains aren't messy or ugly, quite the opposite: They're like a directory of folders, an organized way to sort your presence on the fediverse by service.

In Summary: Go With The Fediverse Flow

It's not worth all the downsides to remove a few characters from your handle, keep that root domain available.

Subdomains are useful, clean and future proofed. Most people setting up Fediverse services will have more than one service and may want a website in the future. Keeping the root domain free and using subdomains reduces friction and prevents problems down the road.

Hopefully in time we can agree on some common "master account" standard with single sign-on and all the bells and whistles which I will happily migrate to... from my subdomains.