This was the final post I made on Oliphant.Social:

oliphant.social/@oliphant/1143…

And this is the first:

oliphant.social/@oliphant/1093…

You can still access them at their original status URLs, despite the fact there is no longer a Mastodon server or even a database running at that domain anymore. You are still able to access it because it's part of a static HTML archive of all my old posts. I used Posty to create the archive, by using my own Mastodon archive. Once I'd completed the self-destruct sequence, I took a modified version of the page that Mastodon displays when an instance begins its self-destruct, and turned it into a memorial as well as a directory to the new location.

With a few handy (but simple) webserver rewrites, the old profile link still works and is a direct path to an archive of my old posts:

oliphant.social/@oliphant

So all the old references should still work, just not the api stuff, or nodeinfo stuff. I thought of setting up a fake nodeinfo, but that might lead to mistaken attempts at federation and I don't think a static HTML site should masquerade that much as an active ActivityPub site.

In my opinion, this is the flow that fedi software should consider. If we can't just migrate the domain to a new server entirely, if “once used, you can never use a domain again” then let us at least create a static HTML archive of the site, that can be easily and cheaply hosted at the same domain, and importantly retain all of the old status references.

This is the path that any Mastodon instance closing down should at least consider. If you're closing down the Mastodon instance, do you have any problem maintaining the old domain and hosting a static archive (much more cheaply, with zero real administration overhead) at the old URL?

Consider the case of Oliphant.Social as a proof-of-concept that you can.

Slurping: Why You Should Migrate To GoToSocial if you want to take your posts with you

Because, thanks to a recent update, GoToSocial allows you to backfill statuses using the scheduled_at date.

This unlocks the ability to use the API to push statuses directly into your account (you don't need to be an admin on the GTS instance to do this, anyone can do this) and at this point in time the tool that exists to do that is Slurp. Admittedly a bit technical, it's at least a solid proof-of-concept and a strong implementation that can be followed (or even natively incorporated into GTS in a later release) that shows how “taking your posts with you” is eminently possible.

To be clear, these are copies of your old statuses, of course, and their urls will be completely different because Mastodon uses a numeric status key and GoToSocial uses ULIDs. But, arguably, your status URLs would also be different if you migrated to a new Mastodon instance too.... right?

As Mastodon doesn't yet allow you to backfill statuses in this way (at least at the time of this writing), if you want federated posts that you can boost, that you can refer back to, with an accurate historical timestamp, that others can share, this is how you do it.

Note: This was not a priority or much of an interest to me on Olifant.Social, especially once I set up the static archive. Though I'm not ruling out the possibility I might import those posts into Olifant.Social again someday, there's no real hurry. With backdating of statuses and my old Mastodon archive safely backed up, there's all the time in the world.

Reasons For Shutting Down and Migrating

I announced the shutdown/migration of Oliphant.Social on January 8, 2025.

People will ask me why I did this, what was my reasoning, so let's itemize them all here, all reasons both noble and ignoble.

In many ways I did a speed run of the typical Mastodon admin lifecycle: From optimism, to growth, to a golden age, to scandal, to mass-migration off the platform and/or account deletion, to a more quiet and humble rebirth, and then to a final shuttering due to costs, burnout, and real-life concerns.

I added one other thing to this journey: There is a migration path to a smaller, mostly single-user instance, with less overhead.

Overhead was a key determinant, and a lot of this is going to be a comparison between Mastodon and GoToSocial, but it's hard not to do that when these differences are a key reason for the migration.

Certainly not the only reason, but definitely a big contributing factor.

Simplicity: Cost, Administration Overhead, and Resources

I've complained about this a lot, admittedly.

Mastodon doesn't officially publish or document any minimum resources for whatever reason.

But here's one estimate.

Another estimate comes from Mastohost itself.

Based on that, let's say roughly 2 CPUs and 4GB of RAM, if you want to have a mostly usable Mastodon instance and that's pretty much for the first 5 or so of you (and in my experience, I needed to double that to get acceptable performance for less than 20 users, including the shitposting yours truly.) Based on the Mastohost pricing above, I was supporting “medium federation” with 4 CPUs, and it gets more expensive from there, even with a managed host.

But that's just hardware. After that, you still have to think about tuning it and scaling it which is a lot of cognitive load.

There are three main Mastodon processes:

• mastodon-web: Which basically handles the HTML and web experience and interface, and probably the REST api as well.
• mastodon-sidekiq: This is a queue that processes a ton of requests, ingests incoming statuses, pushes out other statuses, you can have multiple sidekiq queues and configure them multiple ways, and a lot of how you configure it depends on how many CPUs, etc, you have available.... see the link above about tuning and scaling if you want more details here.
• mastodon-streaming: A streaming service over websockets that pushes data to you, when using the web interface (and sometimes when using other interfaces).

Each of these services runs separately and independently and can even be run from different locations for scalability reasons. They can also fail independently for different reasons, so prepare to keep an eye on your Sidekiq dashboard.

Mastodon also requires you to run Redis. There's also a Postgres database, and it needs PgBouncer and if you don't know what that is, prepare to learn about that, too.

Your head spinning a bit? Unless you get a host who manages this stuff for you, you'd better learn at least a little bit about it.

Then there's object storage, which is required running a Mastodon instance, because that cache could quickly overwhelm your local hard drive storage unless you're prepared to devote hundreds of gigabytes to hosting a cache of other people's data.

And you have to regularly run maintenance (cron jobs) using the admin CLI to clear out old data to keep that cache low, lest you pay for increasing amounts of cache storage in your object cache extending upwards into the multi-terabytes.

By contrast, GoToSocial requires 1 CPU, 1 GB of RAM, and from 20GB to 200GB of hard drive space, depending on whether you use object storage or not. It clears out 7 days of cache, and you can configure that, and that's it, that's your cache configuration right there. You want the caching software to clean stuff up every three days?

You configure nothing. No cron jobs or bash scripts. Because it just works.

Olifant.Social runs on a managed host for $4.75/mo, with 1CPU, 1GB of RAM, and 200GB of storage. No object storage necessary, and that's been battle-tested after federating with everyone my old Mastodon instance federated with, for the past several months.

Island One runs on a DigitalOcean droplet, inside a Docker container, for about $8/mo. 1 CPU, 1 GB of RAM, 35GB of storage, no object storage, running a Sqlite database.

Oliphant Social, however, cost about $100/mo to run on a DigitalOcean droplet, at 4 CPUs and 8 GB of RAM, a managed Postgres db for $22/mo and all to host about the same number of people. About..... 4.

You don't have a separate queue or process for GTS you have to manage. You just run the executable. Island One doesn't even use a webserver like nginx, just the built-in webserver and Lets Encrypt SSL integration of GoToSocial as well.

1 CPU, 1GB of RAM, 20-200GB of storage, built-in webserver and Let's Encrypt SSL.

So. Unless you're planning to be hachyderm.io or the equivalent, I don't really feel like Mastodon is made for this use case of the small admin who just runs to run a small, cheap, low-maintenance social media engine for themselves and their family/friends, or who wants to just grow organically via a “web of trust”, unless you use a managed host.

If I had it to do all over again, Oliphant Social would have been a GoToSocial instance from the start, since I never intended for it to get any bigger than 50 people in my wildest dreams, and was actually intending it to be closer to 25, but it turned out I was perfectly happy when it was actually more like 5.

It's just a better starting point for a new admin, in my opinion. Less cognitive load. Just bring your own UI to the party with GoToSocial. That's the only confusing part.

Post Privacy

I don't think Mastodon takes privacy as seriously as the devs of GoToSocial do, and this is self-evident, for several reasons.

On GoToSocial, your RSS feed is disabled by default. You have to turn it on. In addition, you have a selector for just how web-accessible your posts are going to be. You have Public (the GoToSocial default), Public + Unlisted (the Mastodon default) and then None. With “None” meaning not publicly-accessible at all (which also would disable your RSS feed if you'd had it enabled.)

On Mastodon, by default—and you can't change this as a user—it's all Public and all Unlisted posts. Those are all web accessible, and those are all in your RSS feed.

I complain about Mastodon's RSS feed a lot. Numerous attempts to engage in granting users even an opt-out have been stymied by the dev team or debated-to-death to the point where it seems clear they consider this a silly feature, not a high priority, everyone just gets an RSS feed by default.

It's got all your Public and Unlisted posts in it. You can block as many people as you want, and they can still follow your RSS. You literally need to go into the webserver and block the RSS feeds that way. That's your only real solution on Mastodon, so I hope you run the webserver.

Well, that, or run Hometown, the Mastodon fork.... which means you have to run the server or know someone who does.

And I haven't even gotten into authorized fetch and how, when enabled, in GTS it also applies to user-level blocks whereas in Mastodon it doesn't. (There's some dispute on this point, perhaps it's no longer an issue?)

Or GoToSocial having interaction policies, although there's some encouraging signs Mastodon is planning on implementing this, too, and that GTS/Mastodon might do a sort of collaboration (ie., GTS changing the spec a bit to accomodate suggestions from Mastodon dev team), but that's just based on some stuff I saw mentioned once and I don't have a reference for that, so take it with a grain of salt.

Blocklist Subscription

Are you kidding me? I have evangelized the need for blocklists for years on the fedi and post many resources about that very thing.

I was contracted to write software for IFTAS to push blocks to a Mastodon instance, because Mastodon isn't ready, at least not yet, to build this feature.

And then GoToSocial just comes along and does it, builds it right into the software. A new admin can literally just set up a starting blocklist in GTS and it will auto-ingest and apply the blocks for them, and regularly keep them up to date.

All that code now feels obsolete, irrelevant. Like I'm not saying it was trivial to implement for the GTS devs, but I do know I started hearing about them working on it and then about a month later it was released, so....yeah.

And then came this idea of allowlist subscriptions, too, and that dovetailed into the next part of this equation for me.

I was also tired of waiting for features like this to arrive that seemed to just be appearing every release in GTS that read like a wishlist of everything I'd ever been wanting Mastodon to be.

I'd been dating the wrong person. Or maybe, as a sign of personal growth, I should say instead that I realized I was the wrong person for someone like Mastodon.

Island Networks

I'd been running GoToSocial already, because of island networks, or opt-in federated networks, allowlist clusters, archipelagos.

(We go by many names here.)

It's just the most suitable option. If you're going to need software to run a chain of small instances, scaled horizontally, using a shared allowlist, ideally you need something small that does not require a lot of resources, that is privacy-focused and isn't just going to blurt out all your private network statuses to the entire web, or serve an RSS feed.

Like it's very clear for that reason alone that, for Mastodon, doing “limited federation” is an afterthought.

With GTS it feels more like a first-class feature. Using GTS as the backbone for a new network, I grew increasingly envious, wanting to use it everywhere, awed by its relative simplicity, low administration overhead, and privacy posture. Everything seemed to align with it in a way that felt fresh and exactly what was needed to meet the needs of the moment with island networks.

It felt like, after about six months of island networks, I had made my decision. Why not just close Oliphant Social, and move everything over to GoToSocial? With the archipelago pulling allowlist subscriptions, and Olifant Social doing blocklist subscriptions.

Everything in its right place.

“You Have No Business Running an Instance For Marginalized People”

So let's talk about this.....Oliphant in the room.

Of all the criticisms I have ever received, this one has resonated the most.

Moderators for communities should come from within those communities. I cannot pretend to understand what it's like to be a trans person, though I empathize. I cannot pretend to understand what it's like to be a black person, though I also empathize. I don't recognize veiled anti-semitism in the way a Jewish person would.

I am neuro-divergent, with an autistic child, supporting another disabled person in my own life, so that is my area of intersectionality. I do understand what it's like to be viewed as strange or different but expected to change, to conform, to be something other than who you really are, for the comfort of others who consider themselves baseline or “normal.”

So the best I can, I always try to remember our common humanity that transcends every label and distinction. We all have struggles, and life is fucking hard, and I try to recognize that. I know that probably sounds corny to some, but I haven't lost all of my idealism.

The criticism is valid. It's a responsibility to manage a community, especially an open registration community (even if you have manual review over those applications) that surges to dozens or hundreds or thousands, not to mention the moderation burden then becomes increasingly more consequential. You, and those on your instance, are affecting many more lives in aggregate, after all.

As an admin, if you fuck up, you just branded your entire instance. This is, not entirely as a 'by the way', usually your cue as an admin to shut the fuck up and examine your behavior and see how you contributed to the current state of affairs without denying the accusations or attacking anyone. I realize this is the hardest thing to do in the world, but it's the best thing.

Content to be small

Being the biggest, having the most users, these aren't what's important to me.

My intent at this point isn't to be any kind of big server, or evangelize the awesomeness of Olifant Social and how you should join it, too. Registrations are open, but really only as a way for mutuals or those who trust me and my moderation style to have a way to migrate here if they really want.

I'm going to keep working on Pelago and evangelizing island networks and trying to survive this broken culture, while dreaming and fighting for a better one. I get to spend very, very little time or money worrying about upgrading and administering my GTS server while doing that. So what's a win.

I could use the extra spoons. Despite the crushing cruelty of our present, I dare to believe we're all moving together towards a better future... but to get there, we'll have to spend them.

— @oli 🐘

The Oliphant

2024-08-04 00:44:14

Islands

Islands are opt-in federated networks consisting of a chain of allowlist or “limited federation” servers linked together. Everyone in the network federates with each other, and as such the entire network is more resilient and able to handle moderation challenges simply impossible in the wider fediverse.

Read more below.

• Islands: An Opt-In Federated NetworkA proposal for a new form of fediverse network, a chain of small allowlist-only servers called Islands.
• Setting Up Your Own IslandA simple process for creating your own Island using a GoToSocial backend. Once you have a domain name and a server, it takes about 5 minutes.
• The Archipelago: An Island Network in PracticeMany thoughts on creating and joining (and being kicked out of) an archipelago or “island network.”
• Island ToolkitA codeberg repo with documentation and an installation script for setting up your own island. Additional documentation for the ION Archipelago can be found there, as well.

islands

A quick GoToSocial starter kit to set up an island quickly on a Debian (Ubuntu) server. Learn more about Islands: Opt-In Federated Networks here: https://writer.oliphant.social/oliphant/islands-an-opt-in-federated-network

^Codeberg.org