In a previous post, I talked about things I really enjoy about Mastodon. This time around, I’ll go over some challenges I see for the tool as a platform, product, and ecosystem. Before reading too much into these, note that it’s possible not all of these need to be fixed! Some can be interpreted as an improvement over the status quo of Twitter / Reddit / Facebook (especially if you are privacy-conscious). But these are things that will feel strange for people who are used to those other systems. I’ll also try to offer some mitigation suggestions, or at least expound on why I don’t think they can / should be easily mitigated.

What node do I join?

Absolute governments, (though the disgrace of human nature) have this advantage with them, they are simple; if the people suffer, they know the head from which their suffering springs; know likewise the remedy; and are not bewildered by a variety of causes and cures.

~Thomas Payne, "Common Sense"

The big social networks have the advantage that they are singular. Even though when you’re on Facebook, Twitter, or Reddit you’re locked into their ecosystem, you’re in (a reasonable subset of) the whole ecosystem.

The Fediverse in general and Mastodon in particular don’t work that way. Each node is run as its own separate service, with its own domain name, policies, administration, and even features. This is a lot more like subreddits than, say, having a Twitter account, but even then subreddits tend to have several overlapping similarities and you don’t often, for example, find one where rendering math formulae using LaTeX works and one that doesn’t. This is because every node is really its own web service (with its own backend, rendering rules, server architecture, etc.) and the only thing that ties them together is the ActivityPub protocol they can use to ship messages to each other.

We’ll talk a bit about why it matters what node you’re on, and then some tools you can use to decide what node is right for you.

Why it matters

The short answer is, “It often doesn’t.” To a first approximation, Mastodon is Mastodon; thanks to the ActivityPub protocol linking all the nodes together, you can (usually) just see any user you want from any node. But because every node is essentially a separate service, that level of “flatness” isn’t universal at the level of, say, Twitter. Here’s where you’ll probably see the difference most often:

Different features

Because every Mastodon node is its own service, every node can offer its own features with subtle differences. Among the things I’ve seen vary:

• Special rendering tools. Some nodes integrate text preprocessors to make it easy to do things like render math expressions. My own server is configured to process Markdown by default.

• Text translations. The default Mastodon service comes out-of-the-“box” with hooks to enable translation, but if a service hasn’t installed a translator service they aren’t enabled. This may matter to you (especially because, relative to the common experience on Twitter, Mastodon tends to be more international than US-centric; it started in Germany, so there are many speakers of myriad languages using the service).

• Post length. By far the most hilarious difference between services is maximum length, which is just a constant cooked into the client and server code. ActivityPub is not nearly so opinionated, and many nodes have the length cranked to something other than the default 500 character limit. I, myself, am a wordy bastard and set my limit to 65,535😈.

If this sort of thing matters to you, it’s worth finding out what the settings are on a potential home node.

Different rules

Every node is administered by someone, and every node’s admin (or admin team) chooses the rules they enforce. You can find out the rules for a given node by consulting the /about page of the node.

Server-level de-peering

In addition to the mute / block features an individual user of a node can apply, the node admin can choose to block peering to entire other nodes. This is done for various reasons, ranging from spam protection to protection of users from harm to ideological difference; as you can imagine, while this is a vital feature that is essential to maintaining the health of the ecosystem, it can be a source of regular social media drama; when I joined my first node, I discovered that I couldn’t follow one friend because at some point, the admin of my node decided that furry content was unacceptable and de-peered the node hosting my friend’s acount (which to my knowledge had never posted any furry content). This effect can create wide gaps, especially since some admins choose to use shared blocklists, which can magnify the amount that one node’s bad behavior can isolate them from the network.

All of that having been said, in general I haven’t seen this effect much and would consider it minor (although I may be an outlier, given my circumstances).

Search

I’ll go into detal later, but the node you are on can matter to how useful the search feature is. Search will find content on your node (posts by other users on the same node as you) far more readily than content on other nodes.

Strategies and tools to wrestle the complexity

Just go with your friends

One very easy solution is to look at the nodes your friends are already on and pick one of those. Users on one node are like being in the same neighborhood; in general, a Mastodon node will make it easy to see the activity of poeple on the same node as you. If a bunch of people you know are already on a node, and you’re comfortable with that node’s rules and features, just make an account there!

Use a list or tool to pick

The people who develop and maintain Mastodon and are invested in its success know this complexity is an issue, and they’ve created tools to help sift through the complexity. Two I am aware of:

• The “joinmastodon” server list. The Mastodon company (Mastodon gGmbH) maintains a list of known nodes that is curated for active moderation, reliability, and notification of users in the event of a need to shut down. You can filter it by region and interests. This is how I found my first node; I can recommend it.
• The instances.social wizard. This is another list of instances with a fancy wizard on the front to help you track down an instance that will work for you. I don’t know much about it myself, but it seems to work alright!

Run your own node

This is, of course, the nuclear option. But it has many benefits.

Since Mastodon is an open source web application, you can choose to just run your own instance. You can let your friends join or run as a solo node and be your own admin. I’ve been doing this for several months, and I’ve enjoyed it. It’s not for everyone (you’re going to have to maintain your hardware, get connected with a domain name to the worldwide web, etc.), but it’s been very rewarding to me. If you go that road, I’ve made some notes on the process that might be helpful.

If you go this road, feel free to drop me a note; I’m happy to help!

You can always move

One of the neat things about Mastodon is that the developers recognized that people could find themselves wanting to change nodes eventually. To that end, the service includes a protocol for reporting that you have relocated from one node to another. To do so,

• Create an account on the new node
• On your new node, navigate to Preferences, then Account, and you’ll see options to move. Select “Moving from a different account”.
• In the page that comes up, enter your username@domain on your old account to create an alias. This will notify other servers that you used to be known by that name.
• Wait about 24 hours; processing of account moves in the network is exceedingly slow.
• On your old node, log in and select the “Move to a different account” option. Identify the account you’re moving to. Your account on this node will now start notifying other Mastodon nodes that you’ve forwarded and any followers you have will be auto-updated.
• One last step: go to Preferences -> Data export and export your Lists, Blocks, Mutes, Domain blocks, and Bookmarks. You can import them on your new server to save yourself some setup time.

This process isn’t exactly foolproof; if the server you’re on unexpectedly shuts down or dies, then poof your data’s gone (if you own your own website somewhere, your identity needn’t go away; there is a way to set up an alias using webfinger on any static site you control, then use me@mysite-where-the-webfinger-is.com to redirect to your actual Mastodon account). But for most nodes (espeically the nodes listed in the previously-mentioned tools, that’s an unlikely scenario.

Whew! That was a lot, but hey, the question of choosing a node turned out to be deep. If you’re still here, there are two more challenges I see Mastodon facing. Grab a snack and a bathroom break and feel free to read on.

The domain security model and accounts

Probably the biggest difference people see using Mastodon vs. using any other (centralized) social media site is the fact that each node doesn’t know who you are until you tell it. So if you browse across many Mastodon nodes, or click a link to a Mastodon post shared on some web page, you’ll see it on the node it originated on, not your node. Then, if you try to interact with that post, you’ll usually see some variant of this redirect dialog.

You now have to type in the domain name of your home server to get redirected, where you can then do the thing you wanted to do.

Well that’s annoying. What is this?

What you are seeing is a consequence of browser cookies and the domain-based security model, which is fundamental to how web browsers (and web browsing) work. Let’s go on a short history trip.

Way back in the dark ages of 1994, browsers were young and still in flux. Developers were trying to figure out how to maintain information about what a user was doing on a site without having to store all that info on the site’s server. The solution they came up with was to copy an existing solution from UNIX programs and allow a server to tell the browser “Hey, here’s a piece of data I want you to hold; give it back to me when you make another request.” Now, sites had a place to store “session” information (such as how you’re logged in, your username, or what stuff you have stored in an online shopping basket).

But almost immediately, developers realized these cookies could easily leak data if the browser handed them to every server that asked. It’d be awful, for example, if you were logged into your bank and some random server could grab your bank’s cookie, hand it to someone, and that person could trick the bank’s server into thinking they were you! So your browser can only send those cookies to some servers. Which ones?

Developers settled on the rule being “If I’m sending a request to the same domain that hosted the page that set the cookie, I’ll send the cookie too.” So when yourbank.com sets a session cookie, only pages hosted at yourbank.com and its subdomains can see that session data and know you’re logged in.

But here we see the problem! Because every Mastodon node is hosted on its own separate domain, and the Fediverse of nodes is decentralized, there’s no central server holding everyone’s identity, nor is there a mechanism for your browser to hold the information “Hi, I’m Mastodon user @mark and my home node is mastodon.fixermark.com, so if you have to do any Mastodon stuff just redirect me back there.”

Because of these issues, to protect your privacy, foreign Mastodon nodes have to ask you to volunteer your home node domain so they can ask your browser to take you there, because there’s no way for them to get that information out of your browser. Perhaps some day a method could be added, but it would require both a change to the web standards and support by browsers themselves.

In the meantime, yes, it’s a usability wart. But a small one, and it’s protecting your privacy. Just think of that little dialog as a butler asking visitors to state their business before coming into your home. Aren’t you fancy?

Search is weird

Probably the biggest shock to anyone bringing Facebook, Twitter, or Reddit preconceptions into Mastodon is how different search is. All of these services are centralized, so they can crawl all the data in the service and make it all available to a search query (modulo privacy settings, time, failwhales, etc.).

A Mastodon search does not search every node. It is (with exceptions, we’ll get there!) scoped to the node you are on. So searching for hashtags, plaintext (recently added), etc. is scoped to your node, which means you’re searching

• Accounts on your server
• Accounts anyone on the server is following
• Accounts on servers your server is connected to via a relay

So if you’re on one of the big nodes, like mastodon.social and its 276,000 active users (as of today), search works well. If you’re on a smaller node, you see less. If you’re me and running your own node? Hah. Search is not for you. Find content by following friends-of-friends.

This isn’t precisely by design (lack of support for global search is a practical limitation), but it does have the nice advantage that you see generally less “dogpiling” on Mastodon. I personally think that the ability for people to pick a keyword or hashtag, search all of Twitter for it, and harass people talking about that topic was maybe not Twitter’s best feature. But it’s something to be aware of and may impact what node you choose to be on.

Note that there a couple of exceptions to these rules. Seaches for specific URLs will show the result if that URL is a post on a Mastodon node or a user. And searches for @user@domain will query out to the Mastodon node at domain to see if @user exists, and show you that person. Those searches are how you can access people and posts outside your server to interact with.

Note: The search rules are a subset of the visibility rules, which fedi.tips does a good job of explaining here.

So that’s the whole list. On the whole, these issues don’t really bother me in my day-to-day and I barely notice them using Mastodon anymore. If you can look past or mitigate them, I think the benefits to Mastodon far outweigh the drawbacks.

I hope this was useful! Feel free to follow me on Mastodon when you join up!