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 Mastodon and how it differs from Twitter. Everyone else seems to be doing it, so why not?

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

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 Twitter via Moa, because I will stick around on Twitter 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 mastodon.social 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.

The first thing I realized about Mastodon is that I have zero interest on its “Home” and “Federated” timelines, much in the same way I had no interest in Twitter’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 mastodon.social 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 hachyderm.io (which many techies seemed to flock to during the knee-jerk phase of the Twitter 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.

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 Twitter (despite the hugely clunky mobile interface for that), but there’s a twist regarding trying this in the Fediverse: In Twitter, 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 Mastodon (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 timeline¹.

Another thing about the way lists work in Mastodon 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 Mastodon 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).

Funnily enough, I’ve always wanted to follow hashtags on Twitter, and Mastodon 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 Mastodon 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.

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 Mastodon behaving exactly like Twitter (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 Mastodon 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.

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.

First off, the web, that grand equalizer. I tend to use the “advanced” Mastodon 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 Mastodon 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 Mastodon 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.

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

ActivityPub Exploration

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

That is driven by a mix of reasons–curiosity about ActivityPub, 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.

First off, I started implementing my own ActivityPub 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.

A lot of ActivityPub 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 Go. 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 PostgreSQL as a back-end store and leveraging its excellent JSON extensions to offload some processing and matching.

But the Achilles heel of Mastodon as currently implemented atop Ruby 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 Mastodon 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 already written about and intend to contribute to. Its core design avoids most of the problems with scaling ActivityPub, it has a solid foundation and (although it depends too much on PostgreSQL) 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 Elixir internals, but Erlang/OTP make for a pretty much bulletproof foundation.

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

Pleroma has a rather checkered history, which includes the Akkoma and Rebased forks². 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 Twitter 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 Mastodon 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 Elixir 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 & pave³.

And after deploying 4 or 5 instances of Pleroma in various environments, I realized that for some deployments I’d need specific versions of Elixir 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.