This article describes how to migrate your subscriptions from GotoSocial to Mastodon. I recently made this migration; I talk about my motivations here.

This procedure doesn't handle getting folks over to your new account. It will get you a list of your subscriptions that you can import with Mastodon's data import feature so you don't have to re-follow everyone by hand.

I'm not aware of an account migration or user-facing data export feature in GotoSocial, so you'll need access to your instance's database (or help from someone who has it, anyways). With those caveats out of the way, here's the procedure.

Extract your Subscriptions

To get your subscriptions (or “Follows”, as the database calls them), you'll first need to get your user id:

SELECT username, id
FROM accounts
WHERE username = 'YOUR_USERNAME_HERE'

Once you've got the id, you can plug it into the following query to get your follow list:

SELECT
  accounts.username || '@' || accounts.domain
  AS 'Account address'
FROM accounts
JOIN follows ON accounts.id = follows.target_account_id
WHERE follows.account_id = 'YOUR_ID_HERE'

You'll need the results of this query as a CSV file. There are lots of ways to do that; I used the CSV export feature built into Datasette because I was already using it to figure out the data.

Upload to Mastodon

Once you've got your follows in a CSV file you should be able to import them using Mastodon's data import feature. It should be available on your Mastodon instance's Settings page under Import.

As the trajectory of the bird site got clearer and nastier late last year I decided to migrate to the fediverse. I didn't want to end up on another platform controlled by a petulant tinpot dictator, so I decided to see if I could host my own ActivityPub server. Mastodon looked pretty intimidating, but GotoSocial is a smaller, lighter, program that (approximately) inter-operates with Mastodon (yay, federation!).

I ran that server for a couple of months, but eventually decided to shut it down and migrate to Hachyderm.io. I did this for a couple of reasons:

• GotoSocial ended up being the most resource-intensive thing running on my home-server, and the architecture of ActivityPub meant I was putting (proportionally) more load on other servers than I needed to. This isn't to say that GotoSocial was doing anything outlandish, but ActivityPub is a chatty protocol and I try to be mindful about spending compute.

• Hachyderm has an explicit governance structure, one developed by folks who know what they're doing a lot better than I do. Holding safe, communal online space seems like a really valuable skill, and I'll learn it better hanging out on a shared instance than I will in a private silo.

Atomizing all web hosting into parochial little home-servers isn't sustainable or desirable, and Hachyderm is a cool project blazing a different trail, so I made a donation to help pay for hosting and made the leap.

I had accumulated a pretty lovely feed of subscriptions, and that kept me locked in for a while, but the beauty of self-hosting is that I had the SQLite database with all my data in it, so I was able to figure out a procedure for migrating (which is described here).

I just published the first (v0.1.0) release of tiddly-wiki-server, which implements the TiddlyWiki WebServer API in Rust using Axum, SerDe, and TiddlyWiki.

Motivation

One might ask why a new TiddlyWiki server is necessary, since

• TiddlyWiki5 includes a first-party NodeJS web server, and
• one of TiddlyWiki's beautiful features is that it works as as static HTML file.

These are valid points. I confess, this project fulfills quite a narrow use case: I like to self-host my tools on a small, cheap VPS, and the first-party NodeJS server consumes about 100MB of RAM. This isn't huge, but it's a decent chunk of my available resources. This server consumes much less (about 10MB, and that's before I've done anything to optimize it).

This was also a project that let me combine two technologies that I like an awful lot, so if it seems self-indulgent, well... maybe it is.

Components

The server makes use of some very nice Crates; I'll mention some of the big ones:

axum, a web framework

I've tried a number of Rust web frameworks (Tide, Rocket, simple-http-server); this one's the first one I feel like I really understood and was productive with (though that might also just be that I'm slowly getting better at Rust). Of particular note is that Axum is compatible with tower-http , so many services and middlewares that you might want already exist.

rusqlite, a SQLite binding

I use SQLite for most of my tiny side projects; this one's no exception. The TiddlyWiki back end mostly treats tiddlers as opaque bags of objects, so the database is little more than a key-value store.

serde_json, a loosely-typed JSON interface

If you're reading about Rust you're probably familiar with serde, but since I wanted to retain TiddlyWiki's fairly open schema I needed an ergonomic way to work with un-typed JSON objects.

Future Work

There are lots of ways this project could be added or improved:

• More testing; I want this server to be feature-compatible with the first party server.
• User authentication and access control
• Streaming large responses to keep memory small

If any of that sounds interesting to you, pull requests and bug reports are very much welcome!