How I Use Mastodon

It’s the quiet week before New Year’s, so I thought it worthwhile to tag some loose notes together and take a snapshot of what I’m doing with and how it differs from . Everyone else seems to be doing it, so why not?

The author riding into the Mastodon jungle, art by Stable Diffusion

Spoiler: It’s really not that much different. But it is an opportunity to ponder why you use social networks, and to optimize how.

The Basics

Let’s get the basics out of the way–and by this I assume you’re tired of all the “What’s the Fediverse” five-bullet items that never go anywhere and would rather have five sets of facts:

  • I currently have multiple Fediverse accounts, going back to 2018 or so. I’m fine with the idea of multiple servers. In fact, in this age of vertically integrated identity where losing access to your Gmail can wipe out all your other cloud services, I prefer it as a redundancy mechanism.
  • I’m currently cross-posting to via Moa, because I will stick around on until it burns down to the ground (and because many people I follow are still there).
  • I’m not amazingly interested in self-hosting, because as a former postmaster and game server admin I have more than enough experience in dealing with the people and legal angles of hosting a server than most people, and believe me, it is not something to be taken lightly. But it is something I’m considering doing for a small community–not for my own sake, though.
  • I don’t feel any special allegiance to any particular (public) online community (more on that later).
  • I want to have a mainstream, relatable, experience, and not a quilt of patchy UX and server software.

That’s why I think will be my primary identity in the Fediverse for the foreseeable future, even though apparently many people tend to consider it slow, poorly moderated and a challenge to filter out due to its scale.

Timelines Are 66% Useless

The first thing I realized about is that I have zero interest on its “Home” and “Federated” timelines, much in the same way I had no interest in ‘s default “Home” timeline–I only used the chronological one, since the only “suggestions” that matter to me are the posts (or re-posts) from people I actively decided to follow.

I’m not joining a social network for the ambiance, I’m doing it for the people, and although it’s perfectly natural for me to stumble upon new folk to follow, I actually have an incentive to minimize the number of people I follow directly–it’s called “attention span”, and is a scarcer resource than unfettered time.

On a generic timeline things quickly get out of hand when you follow anything above 150 people, especially if like me you only really check the timeline once or twice a day–plus the time offset I have with the US usually means there’s a lot of catching up to do on my main timeline over breakfast, and I, for one, would like to keep my screen time down for anything that is not creative output.

So I never, ever look at the local feed, let alone the federated one. Perhaps that’s because I’m mainly on and it is not a “small community” (there are nearly a million users there right now), but to be honest I also don’t feel a need for joining any of the more community-specific servers.

I do have an account on (which many techies seemed to flock to during the knee-jerk phase of the exodus in November), but I’ve yet to feel drawn in and I’ve learned to be wary of bias in small, close-knit communities, even progressive ones.

Lists Afford Focus

The challenge of keeping track of things is why I like to use lists as “topical timelines”–I will add people to lists based on broad categories that align with my interests, and switch between lists to quickly check what’s up in those circles.

This is something I did before in (despite the hugely clunky mobile interface for that), but there’s a twist regarding trying this in the Fediverse: In , you don’t have to follow the people you add to lists, which means your personal timeline doesn’t have to show everything.

But on (at least in the mainstream version) you have to follow people to add them to lists (otherwise their server would not know to update yours when they post), and there is no way to filter out the people you add to lists solely from your personal timeline1.

Another thing about the way lists work in is that, sadly, you cannot get an RSS feed out of a list (I suppose that’s partly because lists are private to you, but that shouldn’t really matter). Fortunately provides an easy-to use API, so I have been hacking together a [Node-RED] flow to publish feeds from a couple of lists.

It mostly works, but I haven’t sorted out all the edge cases yet (you have to account for replies, boosts, likes, etc., and render them out in meaningful HTML, like OpenRSS does).

Hashtags are Key

Funnily enough, I’ve always wanted to follow hashtags on , and does that in absolutely the right way (notwithstanding federation quirks, since there have to be enough follows for you to get tagged posts from other servers).

This is almost as great as lists for me, but, again, sometimes I wish I was only seeing posts from specific hashtags when I specifically switched to viewing them, and, just like people you add to lists, following a hashtag in adds those posts to your main timeline–so a trending hashtag has the potential to turn your timeline to mush in no time flat.

Which means I’m caught in the middle between treating hashtags as a way to follow interesting topics or to waste time. Maybe, sometimes, both.

Nevertheless, it’s a great feature to have–I just wish that I could mute them from my timeline if they’re not posted by my direct followers.

Downsides So Far

A lot of people miss quote tweets and other Twitter “features” that Mastodon specifically avoided implementing, and are making a fuss about it for “cultural” reasons–I honestly don’t care about behaving exactly like (and if I want to quote a post, I can always post a link to it), but I do care about some things that federation “breaks”:

  • Search is the top casualty, because even though you can search for people, searching for current posts about a specific keyword that isn’t a hashtag just doesn’t work the way you expect, period. It’s a downside because it only really searches things you posted or that are in your instance, depending on what server software it’s running–but, more to the point, it is almost impossible to find stuff a few days later unless you bookmarked it. Bookmarks are a great feature–use them.
  • I’m going to repeat myself, but this is important: Being unable to see posts from people I add to lists only in lists is a major downside, since there are people (or bots, or entities) whose posts I definitely only want to see on demand. Same goes for hashtags.
  • Post length and formatting varies depending on server, which is, well, annoying. I like that the default is 500 characters because you can have a bit more cogent discourse, but people in a Pleroma instance can post up to 5000 characters at a time, which kind of makes for one-sided arguments.

And, of course, nobody agrees on what kind of markup to use for emphasis, so useful things like bulleted lists are off the menu–but that’s kind of besides the point.

Client Software

Like a gazillion other people, I’ve been trying out all manner of client software, mostly for mobile–and since I have an M1 Mac, also for macOS.

What I use

First off, the web, that grand equalizer. I tend to use the “advanced” interface when I am on Linux, since it is quite similar to TweetDeck (and almost as polished, although I really don’t like the compose window).

That also sort of works on an iPad if you add the site to your home screen, but I would much rather have a native client there.

On iOS and macOS, I am still using MetaText despite the developer having gone on hiatus. It “just works”, and is the most reliable by far. And since it’s Open Source I still have a faint hope if it being forked or maintained into the future.

Other iOS clients I’ve tried:

  • The official one, which works but I don’t actually like.
  • Mammoth, which is being developed at a breakneck pace but is still quite buggy and has two major issues from my standpoint: it stopped running on the Mac (i.e., it runs, but crashes if you look at it askew) and it seems to be going commercial in a weird way (featuring a specific server), which makes my spider senses tingle. Weird indie is usually good, but weird commercial has never turned out so.
  • Tusker gets most things right on my iPhone, but I just can’t get it to login on an iPad or Mac for some reason.
  • Mastoot is competent but lacks a lot of features.
  • Toot! is just unbearable to use for me due to all the animations.
  • Tooot works and has likely the best list browsing interface, plus the saving grace of good font size controls. It’s almost as good as Metatext, but looks pretty awful on an iPad unless you use Stage Manager and has some quirks on the Mac.
  • Pixelfed now has an iOS app in beta. It is not really a client , but has enough interoperability to be interesting (also because I am considering posting photos there).

I haven’t tried Tapbots‘ Ivory, or any of the other upcoming commercial iOS apps, simply because I couldn’t get a Testflight slot yet (and being offset from the US by 4-8 hours usually means you only read announcements far too late to hop on).

I have high hopes for Ivory even though I somehow never really stuck to Tweetbot, but I also have a set of things I am looking for in a client, especially for iOS.

What I Want In an iOS Client

After a few weeks of jumping around various clients, these are the features I look for:

  • It absolutely must not have any irritating animations (Yes, Toot!, I’m looking at you).
  • It absolutely must have the ability to resize text independently of the OS.
  • It must support multiple accounts.
  • It must allow me to “Load More…” posts and/or not mess up the position I’m in when I’m catching up on a timeline overnight.
  • It must have sensible threading for replies.
  • It must let me treat lists as first-class timelines–i.e., I want to quickly switch between Home and my “Friends”, “News”, etc. lists, without having to dig for lists inside a three-level menu.
  • It must run on Apple Silicon Macs. There’s just no excuse.
  • It should display both the time the post was boosted and when it was originally posted.
  • It should display like and boost counts inline.
  • It should display the name of the person boosting a given post before the actual post, but without messing up the layout.
  • It should either also let me use hashtags as a timeline (so I can, say, flip between home and #3D Printing quickly) or have my followed hashtags on tap (again, without my having to search for them).
  • It should have a customizable action bar (so far, I have seen zero clients that allow me to customize what shows up at the bottom of the screen, and that just happens to be a UX best practice for iOS apps). I just don’t want to waste icon space with global feeds, news, VIP users or whatever gimmick the app thinks is valuable enough to put on the action bar.
  • It should have large, friendly media/OpenGraph link previews.

Keen-eyed readers will notice I am not mentioning notifications in the list above. I have progressively turned off notifications from everything related to social networking (except a few choice things), and I honesty don’t know if I will ever turn them back on.


I’ve also been hacking away at my own implementation and setting up a few (non-) servers to see how they work.

That is driven by a mix of reasons–curiosity about , an interest in setting up a small, reliable and low maintenance server for around 50 people, and wanting to understand the scaling factors involved on getting it to run at cloud scale.

The Protocol

First off, I started implementing my own server to understand the protocol. The first thing that comes to mind about it is how inefficient it actually is: There’s no real concept of live updates or transaction batching like I have to deal with in the telco world, so it’s all “just”… webhooks, really, and the protocol is almost insanely chatty, with servers pelting each other with reams of HTTP requests at the slightest provocation.

It is, sadly, a child of the W3C era, and thus relies entirely too much on lobbing chunks of JSON to and fro via HTTP to various endpoints you discover along the way instead of (say) using persistent connections, binary payloads and a topic structure (but I’m biased here).

And yes, you can batch updates from your server to others and optimize connection handling, but you’re still at the mercy of being pelted willy-nilly with updates from other servers, and there are no decent fallbacks for fully static sites.

Data Representation

A lot of is just begging for using a graph database as storage, and you can go a long way by just using JSON documents on disk (my first toy approach did just that).

However, handling JSON is a bit challenging in languages like . It was no surprise to peek into the GoToSocial models folder and start drowning in nested structs… So runtimes with good JSON support have a natural advantage here.

However, this has also percolated down into broader architecture choices–as far as I can tell most people are using as a back-end store and leveraging its excellent JSON extensions to offload some processing and matching.

Queue Handling

But the Achilles heel of as currently implemented atop is the backlog involved in reaching out to all the servers where there are followers for a local user (or replies and likes to be delivered) and updating them.

Every single post about deploying will go on at length about Sidekiq and how to optimize its queue processing, and, in short, it just doesn’t scale without some pain. Plus it is a resource hog that I will never want to manage myself, so I have been looking at alternative servers.


The most promising alternative server for me is Takahē, which I’ve and intend to contribute to. Its core design avoids most of the problems with scaling , it has a solid foundation and (although it depends too much on ) it feels like the logical choice for easy to maintain, small-to-mid instances.

Well, once it has more features, really. It’s still a work in progress.

But if I wanted to set something up now, I would likely bite the bullet and deploy Pleroma. I don’t really like its internals, but /OTP make for a pretty much bulletproof foundation.

Things To Watch Out For

In fact, I’m going to use Pleroma as an example of the challenges involved in picking an server–and the first (ironically for a federated environment) is fragmentation.

Pleroma has a rather checkered history, which includes the Akkoma and Rebased forks2. But the mention of either of which seems to raise some tempers, and it saddens me a bit that choosing server software (and forking it) is associated with bias and conflict.

But quite a few nooks and crannies of the Fediverse are highly prone to cultural or ideological feuds of some kind, and make seem like a sane place, so I suppose this will be par for the course regardless of whatever software you use.

The second challenge is UX, since Pleroma decouples the web front-end from the back-end.

The plus side is that it allows you to run very nice front-ends like Soapbox 3.0 (which, unfortunately, also seems to be embroiled in controversy) or a plain clone of the web front-end, but they both have weird UX gaps where you lack admin options, so the immediate downside is that you really need to dive into the CLI (or the default front-end) to actually manage the server.

Finally, the front-end and back-end being entirely separate pieces of software leads me to the third challenge of deploying Pleroma: plain and simple ease of maintenance.

I can resort to Docker images to wrap the components, but will always have to deal with mix and other annoyances to rebuild the OTP app, and have to make sure the front-end lifecycle (upgrades, configuration, etc.) matches the back-end.

Granted it’s not the kind of thing you’d do on a daily basis, but running a server is 5% deployment and 95% maintenance and upkeep, and that also includes fail-over, backups, and the occasional nuke & pave3.

And after deploying 4 or 5 instances of Pleroma in various environments, I realized that for some deployments I’d need specific versions of and several dependencies that have to be built in place, plus I had to run mix to rebuilt he OTP app for a couple of simple configuration changes that really ought to be environment variables.

So no, thanks. At least not yet.


The Fediverse can be a nice place, but it needs work. Lots of work, and definitely a lot more maturity as far as its plumbing and server platforms are concerned.

I will keep looking for a decent iOS client and poking at Takahē as my most likely self-hosting solution, but I strongly suspect I’ll be setting up a Rebased instance in the near future for at least one little community, and I’m already wary of the effort it’s going to entail.

  1. Pleroma seems to allow you to build lists with people you don’t really follow, but I don’t have an account on a live Pleroma instance yet and the test instances I’ve stood up weren’t federated, and as such I couldn’t really test this. ↩︎

  2. Incidentally, Rebased supports quoting posts, and IM chat among users, so it feels like a great small company/community server. ↩︎

  3. Then there’s the other 95%, which is handling people and moderation, and filtering, and whatnot. I’m not going to go on at length about that. ↩︎

This page is referenced in: