FTO Update, June 2023 to June 2025


Wondering why it’s been so long since I gave an update? Allow this table to explain:

Month Cost
November 2022 $26.06
December 2022 $8.73
January 2023 $4.75
February 2023 $0.19
October 2023 $32.94
October 2024 $32.94

The past two years have played out exactly as I expected. I’ve kept up with software upgrades, watched for instances to block, and otherwise carried on boosting like a madman. As you can imagine, it’s tough to motivate yourself to report “nothing to report” over and over again, so I’ve gotten lazy about updates.

At long last, though, it is time to end that lazy streak.

Welcome, PZ!

PZ has now migrated from his old instance, octodon.social, to FTO after the former announced it was shutting down. I’d planned to type up a blog post on that item, and I may still do so, but it boils down to a second draft of this trilogy on Mastodon. For instance, it doesn’t require much to take this observation…

A number of smaller Mastodon instances were mobbed with new sign-ups in the past few months, and the admins found themselves buried under mod workload and unexpected bills.

… extend it to cover long-running instances that have accumulated tonnes of accounts, but haven’t scaled up their mods and admins to match, and hit on the nut of what I’d like to say about octodon.social.

I expected PZ’s transition to be a major test of FTO. He has the highest profile of the entire network, with an order of magnitude more followers than lil ol’ me, and skews more towards the permissive side of speech than I. At minimum, our ridiculous block list would likely filter out a non-trivial number of his followers, causing all sorts of complaints.

And yet, it’s been smooth sailing. The instance was pegged at 100% CPU usage for a bit, while every one of his followers was informed of his new home, and that’s about the extent of it. No grumbling, no complaints. Disk usage has gone up (more on that shortly), but we’re nowhere near a point where it has me worried. Chalk this one up as a straight-up success.

But Speaking of Disk Usage

Maybe two weeks ago, I noticed the instance had stopped responding. I checked our front-ends (that’s also foreshadowing), and every single one had gone sideways.

One big problem with decentralized social media is that it’s, well, decentralized. Let’s say (theoretically) a popular account on Mastodon shared a dozen multi-megabyte JPEG images of Grand Theft Auto 6. For centralized social media, this is no big deal; storing every photo on the network already chews up terabytes of space, so an extra hundred megabytes is effectively a rounding error. Even if it was, the benevolent dictator could quietly downscale and re-compress the images behind the scenes, or delete the images once they become a nuisance, or even block the images from being posted at all.

On decentralized social media, though, nobody’s around to enforce those limits. This leads to some truly ridiculous files being passed around, for instance a shocking number of people share photos as 3840x2160 pixel PNG images. It’s great to see a pair of officials just about to raise a rainbow flag up a flagpole, but did that really require a 16MB PNG when a 1MB JPEG would look identical?

Spraying these massive files out to all your tens of thousands followers is a terrible waste of bandwidth, so Mastodon instead asks that the thousands of instances containing those followers cache those images. Each instance then shares their copy to the appropriate followers, spreading out the bandwidth hit. It’s a great idea, but it assumes every instance is willing to spend some cash so they can store the occasional 16MB PNG, or run by someone who knows how to periodically cull the cache, or some combination of both. As a puny instance that’s run on pocket change, we can only rely on aggressive culling, and I thought I had all that worked out years ago.

But PZ joining the party not only asked our cache to store more files, it also shifted what was being cached. My scripts focused on culling images, since my follows rarely shared videos, but PZ’s follows were a different story. The cache gradually filled up with 150MB videos, and eventually they consumed every free byte of the virtual hard drive. As a side-effect, some of the processes that make up a Mastodon instance started flailing around and effectively died.

Enter: me. Once I figured out some of the above and started trashing the biggest files in the cache, a few Mastodon processes immediately healed themselves, and for the rest a manual restart brought them back. I’m still not sure how long FTO was down for, but I figure it was no more than a few hours. With a temporary fix in place, I turned to preventing this from happening again.

That took more effort than I figured. There were a bunch of zero-byte files in the cache, for instance, which I initially blamed on my script trying (and failing) to replace images when the virtual hard disk was full. After a few days, though, I realized it was actually due to a bug where my script would clobber an image it couldn’t shrink. Deleting the empty files was easy enough, but Mastodon didn’t seem to be automatically repopulating the cache. I had a manual way to force that, but not enough disk space, so I had to rummage around in the sofa cushions to free up extra space. As of a few days ago, though, all those missing files seem to be back, and my modified scripts are doing a great job of culling the cache.

We’re nowhere near the point where I have to consider adding more storage, I bet we could handle a few more PZs before I start sweating.

And Then There Were Four

It’s long been my goal to collect as many front-ends as possible for FTO, catering to different needs. A while ago I ran into someone with a really locked-down browser, and manually enabling Javascript for every domain was a huge pain. Since I had always wanted to add a Javascript-free front-end to our collection, I bumped that up the priority queue. We now have four front-ends at your disposal:

Vanilla Mastodon: I don’t think the default web interface gets enough love. It comes in both “simple” and “Tweetdeck” flavours, offers extensive keyboard shortcuts, and works well on both mobile and desktop. You can even install it onto your phone as a progressive web app, so it looks and feels like a native application. Using it does require an account on FTO, alas, and I’m not a fan of the icons running down the right hand side of the mobile interface.

Phanpy: Still my favourite way to browse Mastodon on the desktop. It offers pretty much every feature people complain is missing from Mastodon, like notification/boost grouping and “quote boosts,” offers a minimal yet wildly-customizable interface, and has been relentlessly updated by the maintainers. It’s minimal interface is excellent on mobile, and it can also be a PWA, but unlike Vanilla Mastodon you don’t need to have an account on FTO to use it. There are also some keyboard shortcuts, as well. My two biggest gripes: boosting takes more effort than other front-ends, and it isn’t as smooth with multiple accounts as a dedicated Mastodon phone app.

Elk: I’ve softened on this one over time. It sticks closely to Twitter’s default interface, but adds in many of Phanpy’s extras while streamlining the interface. The mobile interface is also excellent on mobile, it’s also a PWA, and you also don’t need an FTO account. It’s the perfect foil to Phanpy, and while it was a pain to get working I don’t regret the effort. Despite being in “alpha” for years Elk is still sluggish to put out official releases, alas, and I still bounce off the Twitter-like feel of it.

Bloat: A “joke” interface that’s surprisingly good. This is the newest of the four, the one without Javascript, and not surprisingly that makes it very performant. The entire front-end loads in about a second, while Elk/Vanilla/Phanpy each require 2, 4, and roughly 6 seconds respectively. The use of iframes means I can click and drag to resize parts of the interface, a pleasant break from most web apps, and the editor offers my choice of typing up posts in plain text, Markdown, HTML, and BBcode. It too does not require an FTO account to use. There’s even a decent collection of keyboard shortcuts! I can’t put in a content warning, alas, and I’m a bit dubious of the developer. They hail from an instance FTO has blocked, but I did spend a bit of time browsing the source code and couldn’t find anything suspicious.

Blatant Foreshadowing

Alas, there’s still a lot to do around FTO. I’ve been slow to fix a few broken but secondary parts of the instance, and years ago I pledged to set up an RSS-to-Mastodon script that automatically posted blog posts via FTO. Hopefully those items won’t take another two years to finish up, and naturally I’ll have a post up to announce their completion. And maybe add another front-end…