Over the Easter weekend 2024, there was a big kerfuffle around a compression tool named xz. Honestly, the story is so amazing that it could be a gripping novel. In fact, what happened is not dissimilar to the book $ git commit murder My Michael Warren Lucas.

A PostgreSQL developer, Andres Freund, was running some benchmarks and trying to reduce the noise from other programs on the system. While doing so, he noticed that sshd would take more CPU than expected during logins, for about 0.5 seconds at a time.

Side note: The reason that this came up at all is that any system exposed to the internet gets regular failed login attempts via ssh, from potential attackers and security scanners of some sort.

So Andres starts looking into where the CPU time is spent and discovers that most of it is in a part of liblzma (the compression format library) and not covered by a symbol – i.e. without an indication in which function it is. This is very suspect. Digging further, it turns out that sshd is backdoored through the installation of xz version 5.6.0 or 5.6.1!

At this point, I highly recommend heading over to https://www.openwall.com/lists/oss-security/2024/03/29/4 and reading Andres’ original investigation posting. Below, I want to resume some more salient points around this story.

Why does OpenSSH even depend on xz?

Normally, it doesn’t, however several Linux distributions patch sshd to integrate systemd notifications. The systemd library to do that also happens to link against liblzma from the xz project. So perhaps the folks complaining about how systemd is so pervasive in modern Linux systems do have a point.

Who wrote the backdoor?

The malicious code has not been written by the original author and maintainer of xz, Lasse Collin. In fact, he appears to be the victim here.

The backdoor was inserted by a second xz maintainer named Jia Tan, who joined the project several years ago. The circumstances of him joining are a story that happens all over open source projects:

At some point, the main development of xz was more or less done. As lcamtuf argued, ongoing maintenance of a stable project “is as interesting as watching paint dry”. So I imagine Lasse struggling with motivation, then someone coming along and offering to become the co-maintainer. They show up with some patches ready to merge. At the same time, several people put pressure on Lasse, saying that “patches sit forever in the queue”, that they are doing a bad job and that this person should just be admitted.

Note that this was years before this backdoor.

They then do the following:

• Jia Tan creates https://github.com/tukaani-project containing Lasse and themselves. The original xz code was hosted off GitHub on git.tukaani.org.
• The homepage moves from Lasse’s server to a subdomain hosted on GitHub Pages, so that Jia Tan has full control over what’s on the page.
• A workaround for a Valgrind failure is added to various distributions. Apparently, the Valgrind failure is caused by code added to later support the backdoor.
• Jia Tan adds plenty of test files (binary archives) with innocent-sounding names to the repo. Curiously, some of them are not actually used in tests.
• Jia Tan creates the official release tarballs on their machine.

The last two points are important for how the backdoor is hidden.

xz versions 5.6.0 and 5.6.1, both containing the backdoor, are released in late March 2024, apparently while Lasse Collin is on vacation.

How is the backdoor hidden?

The payload is effectively contained in some of the binary test archives added to the repository before. But the way they are enabled is amazingly subtle.

In open source projects using Autotools, it is common to not check in generated files (like the configure script) to the repository. After all, they can be generated at any time, right? So what happens is that the maintainer of the code (the perpetrator in this case) checks out the source at a certain tag, runs autoreconf and creates the release archive from the result (e.g. using make dist, which is part of automake). So whatever changes they do to their local copies of autoconf and/or its macros is not checked in to source control! If you look into the git repo, the code enabling the backdoor is not there at all!

What does the backdoor do?

On a Linux x86 system (and only on Linux x86), it hooks up into the signature verification routines used when checking the credentials of someone trying to log in via ssh. The exact way of working is still not fully understood as of the time of this article. According to preliminary analysis by Filippo Valsorda, the backdoor becomes active when the login attempt contains a certain client key (I was not even aware that a client key is sent in ssh logins) and runs some code by calling system. So it appears to be Remote Code Execution, a Pre-Auth Bypass, or both.

In this context, it is probably not a coincidence that some folks saw a much larger number of failed ssh login attempts over the internet:

xz 5.6.0 was released 2024-02-24, around one month ago, and it contained a backdoor.

[…]

There has been an incredible amount of SSH attacks on my server since early 2024. To give you an idea:

root@udon:~# grep -ic 2024 /etc/hosts.deny
5406

root@udon:~# grep -ic 2023 /etc/hosts.deny
763

Who is Jia Tan?

In short, we don’t know. It is probably a fake identity, just like the sock puppet accounts that were used to pressure Lasse to admit Jia into the project.

The back story is that they are Chinese and living in California. There is some speculation that they were legitimate and a second person took over their identity. But this is not confirmed, and I think it is unlikely.

Jia Tan’s GitHub account is still active, though the xz-related repos have been blocked. This does not make it easier to follow along the technical write-ups, or to check out the source for ourselves.

Jia also made 9 commits into private repositories in the last month. I wonder what those are?

In the meantime, Lasse found at least one other malicious commit in the xz source, disabling the use of Landlock sandboxing on Linux. Look at that diff and think about whether you would have spotted this in code review!

Jia also made suspicious commits to other projects, such as libarchive. Again, some of this suspicion may be overblown, but we don’t know.

Would SBOM have prevented this?

Haha lol no.

These were normal-looking releases, uploaded and signed by the regular release manager. If anything, it is helpful to be aware that a larger product contains a version of xz with the backdoor.

What are the consequences?

This could be a watershed moment for open source development. Open source development is currently a high-trust environment, and I fear that suspicion about this case is going to color all sorts of future interactions.

The thing is, all the interactions that Jia Tan had look absolutely legit and standard for open source. It is completely normal that someone who you never met shows up and offers some help and patches. Maybe you meet them years later at FOSDEM, or something. Maybe you never do.

For instance, in NetBSD, there are dozens of people who contribute under pseudonyms at this very moment. To become a developer, we require that another developer meet you in person and sign your PGP key. Maybe that’s a good idea after all.

But for instance, multiple times, I have shown up in some other open source project with a fully formed patch, saying “Here is some code to support my OS or my architecture. You probably cannot verify it as you don’t have this machine. Please apply it, I promise it’s fine.” Until now, I assumed that they would do just that, and was annoyed when they didn’t. But now? They don’t know if I am trying to insert a backdoor.

In the end, this is probably going to introduce more friction and more suspicion of contributors’ motivations into the distributed, open development process. This is bad news for all users of Free software. I would hate it if this destroys the trust-first (you might say naive) culture in open source development.

But let me also offer two more hopeful takes.

• Diversity works. The backdoor targets the largest majority platform for servers: Linux, with systemd, on x86. Running NetBSD or FreeBSD, or perhaps another architecture such as ARM, prevents the attack from working. So by virtue of being on a less common platform, you can lower your risk. This is a basic economic argument: just like other closed source vendors (hah!), exploit writers primarily target the majority.
• Finally, the open source community did not actually do too bad in this! Sure, it was found by a stroke of pure luck. But the malicious code had been in the wild for only about a month. And it had not made it into long-term support releases of major distributions, where it would have made it into a ton of server systems. Compared to the lead time for this attach of 3-4 years, this ended up not being a very successful operation by whichever organization is behind this. So in sum, we got away okay this time.

I installed Fedora 39 the other day. (More on that in one of the next posts.) It has a nifty software installer thing named “Discover”. When I typed “Visual Studio Code” into the search box, it dutifully installed VS Code. As a Flatpak.

This was the first time I interacted with Flatpak, and it did not go well.

Aside: Why VS Code

I want to use VS Code for editing Go code, with gopls, since it provides a really good integration. It turns out that a majority of Go developers use VS Code, so the language server integration is well tested and complete. In short, it’s the well-lit path.

Specifically for myself, there is a second reason: At work, we use a bespoke web-based IDE based on VS Code, with all sorts of integrations to make developers more productive. I have gotten very familiar with this setup, so it makes sense for me to write open source code in this way too and benefit from the muscle memory, so to speak.

There is a philosophical argument that you should avoid VS Code because it is controlled by Microsoft, and it gives Microsoft a certain leverage over the open source Go ecosystem. For what it’s worth, the same argument applies to using GitHub: Such a large percentage of open source code is developed on GitHub these days, and Microsoft could “enshittify” it at any moment if they wanted to. But for both of these, I personally think that it would be easily doable to switch away from them to something free – for instance, move over to Neovim’s LSP integration. In the meantime, I remain pragmatic and use what works for me.

Why not Flatpak

Back to Fedora. I installed Go and gopls from pkgsrc, as you do. However, the Go plugin tells me that it cannot find gopls, or any of the toolchain. Why!? Issue golang/vscode-go#263 has a bunch of people rather confused about this failure mode.

Ultimately, it comes down to this: Flatpaks run isolated from the host OS, which is fundamentally incompatible with developing code in an IDE. Despite the allowlist for access to OS paths, there is no way to allow access to /usr, /lib, etc. This is fundamental to the Flatpak security model. The app runs in a container that is cordoned off from the main OS.

But an IDE for developing native code does need host OS access! It needs to run a build tool, toolchain, native tools, etc. Not only does the VS Code Flatpak not allow doing this, it also does not provide an easy way to install a toolchain into the container. Never mind that I do not want a second copy of my tools. An IDE also needs to be able to run a shell in a terminal.

At this point, I am left wondering: who can actually use this Flatpak, if native compilation is all but impossible? Is it made for frontend devs writing only JS, with all the tooling in JS as well?

Fixes

I am also wondering why the Flatpak is the default type of installation for VS Code on Fedora, given that Upstream has a repository of perfectly fine RPM packages. See https://code.visualstudio.com/docs/setup/linux#_rhel-fedora-and-centos-based-distributions.

The other container-like option would be a Snap, if you are into additional packaging systems on your distro. You can install the Snap in “classic” mode, where it has file system access:

sudo snap install --classic code

My choice has been the native package, and now everything is running fine.

When I used OpenBSD, I was a big fan of bsd.rd: a kernel that includes a root file system with an installer and a few tools. When I invariably did something bad to my root file system, I could use that to repair things. bsd.rd is also helpful for OS updates. And there is only a single file involved.

On NetBSD however, there is usually no netbsd.rd kernel installed, or even available by default. The facility is there, it’s just not standard. To be fair, there are a number of architectures that use kernels with a ramdisk for installation.

Recently, I have been toying with NetBSD on an Orange Pi 5. This is a 64-bit ARM board, using the evbarm-aarch64 architecture. I am booting from an SD card (details in a followup post) but once booted, the kernel does not see the card any more, only the NVMe SSD. So my thoughts went back to bsd.rd and I decided that I want one!

It turns out that there are two ways of getting a kernel with a ramdisk:

1. Building the ramdisk image into the kernel itself, bsd.rd-style. This is called an “instkernel” in NetBSD terminology.
2. A loadable kernel module, miniroot.kmod. The modules.tar.xz set contains an “empty” miniroot module, to which you can apparently add your own image.

I was unable to make #2 work, so I will only be talking about #1 here.

How to create a NetBSD ramdisk kernel

For the ramdisk image, you can use a pre-built “daily” image, which is available at http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/installation/ramdisk/ as ramdisk.fs. Its size is 3072 KiB. Keep that number in mind for later.

For the next steps, you need a NetBSD source tree. The default location is /usr/src but any other location works just as well.

The Orange Pi 5 uses the GENERIC64 kernel configuration but there is no “install” variant. So you need to add a new configuration file, sys/arch/evbarm/conf/GENERIC64_INSTALL, with these contents:

include "arch/evbarm/conf/GENERIC64"

no options MEMORY_DISK_DYNAMIC
options MEMORY_DISK_IS_ROOT
options MEMORY_DISK_RBFLAGS=RB_SINGLE
options MEMORY_DISK_ROOT_SIZE=6144

This disables the dynamic ramdisk size and use a fixed size of 6144 sectors x 512 bytes (= 3072 KiB) instead. It also sets the ramdisk as the root filesystem and defaults to single-user mode.

Now let’s build the kernel. I did this on a Mac but any OS would do:

$ cd /usr/src
$ ./build.sh -O /Volumes/obj/ -m evbarm64 -N1 -j 7 -U tools
$ ./build.sh -O /Volumes/obj/ -m evbarm64 -N1 -j 7 -U -u kernel=GENERIC64_INSTALL

Side note: the obj directory needs to be on a case-sensitive filesystem. On a Mac, you can create a case-sensitive APFS dataset named obj, which is mounted under /Volumes/obj.

Now the magic bit, adding the image into the kernel:

$ /Volumes/obj/tools/mdsetimage/mdsetimage -v /Volumes/obj/sys/arch/evbarm/compile/GENERIC64_INSTALL/netbsd ~/Downloads/ramdisk.fs
mapped /Volumes/obj/sys/arch/evbarm/compile/GENERIC64_INSTALL/netbsd
got symbols from /Volumes/obj/sys/arch/evbarm/compile/GENERIC64_INSTALL/netbsd
root @ 0xc6e328/3145728
copying image /Users/bsiegert/Downloads/ramdisk.fs into /Volumes/obj/sys/arch/evbarm/compile/GENERIC64_INSTALL/netbsd (3145728 bytes)
done copying image
exiting

Now you can copy the sys/arch/evbarm/compile/GENERIC64_INSTALL/netbsd file to the SD card and boot from it. This boots into the NetBSD installer, which also has a (limited) shell available.

In my case, I was able to install the system to the SSD. Success! 🎉

Whenever I send around a Call for Papers for an open source conference, some people reply something like

Unfortunately, I don’t have anything to present right now. My work on XYZ is simply not far enough along.

Or similar. However, this does not matter.

I’ll let you in on a secret: When I was in academia, when someone was talking about their results at a conference, I mostly did not give a shit about the results themselves. (Unless I was working on something narrowly related, which was rare.)

Instead, what I was really interested in was the Intro and the Conclusion. Why did you do this research? What is the bigger picture? What have you learned?

What to talk about in an (open source) conference

The idea for this post came to me after EuroBSDCon 2023, where this type of conversation happened more than once, with different NetBSD and other developers. (I hung out mainly with the NetBSD crowd, as expected.)

Many of the successful presentations in the conference weren’t all that much about own work, the work of developing some driver, subsystem or whatever. They were about cool stuff they do with the OS. What cool stuff can I, the person watching your talk, do with this OS, or with some other OS? What are you using your operating system, or programming language, or whatever, for? Surely you are using it for something? So you are running some web services behind a firewall? You could talk about that! Explain how, say, npf in NetBSD helps you with that.

You are fiddling with your OS on a tiny single-board computer? Bring it into the talk, connect it to your laptop and boot it live!

Example: OccamBSD

One of the more inspiring talks that I watched at EuroBSDCon 2023 was the excellent Michael Dexter explaining OccamBSD. At its core, OccamBSD is a minimal FreeBSD – you build the world and disable all the knobs that can be disabled, so you get a system that’s minimal in size. Why?

• as a study object, to take apart and see what you can do without
• for jails, where you don’t need a mailer daemon to run your webserver

And more. I thought the idea was neat, and I am now experimenting with doing something similar on NetBSD.

So what, I hear you object, but this was presenting the author’s own, finished development work! Well yeah. But development work is never finished. Don’t be afraid of showing things which are not quite ready for prime time. You might find people that like the idea and want to help you.

Example: “NetBSD, not just for Toasters”

At FOSDEM 2020, I gave a somewhat generic talk introducing NetBSD and pkgsrc. Its title was “NetBSD: Not just for Toasters”. To be honest, when I started writing the talk, I was a bit worried that it would be too generic and hence boring.

But to my great surprise, this was my most successful FOSDEM talk ever. The hall was packed, and I had about an hour’s worth of audience questions in the hallway outside. It turns out that people who are not from the BSD community were coming in to this talk to find out what cool things your can do with this, just as I alluded to above.

And I did have some cool things in there, mentioning various emulation and cloud support layers, plus some fun ARM hardware that you can run NetBSD on. And clearly, even if you are never going to try this OS, maybe you got inspired to buy a Pinebook Pro and use an open hardware laptop?

Conclusion

It is hard to judge from your own perspective how interesting your topic will be for the audience. You, as the author, tend to overindex on your own work and take the context in which your work happens totally for granted. Yet, the audience perspective is very different.

• The audience is looking for ideas and inspiration.
• The audience might be looking for a cause that they can join and that sounds fun. It doesn’t have to be finished.
• Even if they will not use the exact combination of things you present, they are looking for an aspect that translates to their own world.

I hope this gives you some ideas for when you are feeling writer’s block when the next call for papers arrives.

PS: The Twitter button is gone from this blog.

I have lived outside the country I was born in for more than 17 years now.

When I lived in France, I eventually had a pretty good grasp of the language. I could give tech talks, write reports, talk to my coworkers, neighbours and friends — including casual banter and that sort of thing. I like to think that I actually fit in pretty well.

However, one evening I watched Qui veut gagner des millons? on TV, the French edition of Who wants to be a Millionaire. And I realized that I would not even be able to get through the initial round of quick-fire questions. Most of the time, I did not know the answer to the 500 euro question! The reason for that is that these questions rely on shared cultural understandings, such as that TV series everyone watched when they were a kid, popular books and snacks and the like. I grew up with different series. I have not watched many of the movies that “everyone” remembers from way back when, such as La cité de la peur or Le Père-Noël est une ordure. La classe Américaine was excellent though :)

Don’t assume cultural context when communicating

It is easy to take your own cultural context for granted. I see this all the time on the Internet, or at work. Yet, in a globalized world, this creates an exclusionary atmosphere, particularly together with a “What, you don’t know that? Come on!” reaction when this gets pointed out.

In my opinion, this is especially true for US culture. People keep showing me pictures of outrageously bad pop tarts, and I don’t know what a normal one is supposed to look like. People assume that I know who the cartoon character in their avatar is. And so on. Europeans generally don’t know these things, as they are not available in their country. I assume it’s the same for Asian people.

This goes in the other direction too, of course. There was a recent controversy on social media because an American influencer in Paris apparently discovered that French people put butter on their sandwiches. There was a lot of snark from other Europeans about how everyone knows this already and that this person was stupid, etc.

So, my tip for communicating (and writing docs or blog posts is certainly a form of communication too): Try to be mindful of your own cultural context that might not be shared by your readers or listeners. Don’t rely on it. And when you are called out for it, don’t double down and give a snarky answer. Be kind.

All of the dominant commercial operating systems in desktop and mobile computing — macOS, iOS, Windows, Android, Chrome OS — are made in the US, on the West Coast. Except for Microsoft, they are heavily concentrated in the SF Bay Area. (Note that I am not talking about free software such as GNU/Linux, BSD, etc., which is probably more diverse regarding the location of their developers.)

Flight Tracking

All of these OSes are very eager to support you with flight tickets and boarding passes. For instance, you can add your boarding pass to Apple Wallet, or Google Wallet, and it will automatically surface when you are at the airport. Very convenient!

I have a flight to Tallinn, Estonia, in a few weeks. Ever since the flight appeared in my airline’s mobile app, my iPhone has been sending me reminders — daily, sometimes even multiple times a day — that it has found data about a flight, added it to my calendar and will be tracking it. Similarly, on iOS, you can pull up the OS search field and enter a flight number to get instant tracking of that flight. The OS will even remember it for a while.

Culture?

Here is the thing though: Try to enter, say, “ICE 79” into the same search field, and you get — nothing.

This made me realize how much cultural influence bleeds into the features that they provide. It’s not like these companies do not care about public transit. Both mobile Wallet apps have good support for things line the OMNY pass in New York City and the Clipper card in the Bay area. It’s just that long-distance, inter-city travel by train is all but nonexistent in the US. A few people take Amtrak, but they are not worth building support for. In the US, people just fly or drive. Rail, transit in general, is something you might use for your commute and that’s it.

Now, there are some technical hurdles to providing similarly good support for trains. For one, the data formats are not as standardized as in air traffic. But that could be changed. Google and Apple do have transit teams. They did make most transit agencies output feeds in GTFS format for real-time updates, plans of which metro line goes where and whatnot.

So if there was a push for a standardized way of supporting inter-city rail tickets, it would probably succeed. But it doesn’t look as if this is a priority for any of them.

I recently made two LinkedIn posts about meetings. I thought it would make sense to reproduce them here for posterity.

Normalize ending meetings early.

If you have scheduled a 1-hour meeting but you are done with your agenda after 30 minutes, there is no need to scramble to think about more things to say. No one will judge you (hopefully) if you just end the meeting at that point and make a more productive use of the remaining time.

Unless you are interviewing a candidate, I guess.

Another post about meetings:

Larry Page, Google founder, famously wrote a memo on effective meetings. It contains the sentence:

“Attendance in meetings is not a badge of honor.”

This has resonated a lot with me. What it means is: when you realize your presence in a meeting is not needed, you find yourself disconnecting or even checking emails on your phone, then leave. Of course, if you know this before the meeting, then you can just decline the invitation. The hard part is getting out while you are sitting in it.

There are a few techniques to do this, such as simply saying sorry and leaving the room. It takes guts (and psychological safety!) to do that though. I know that some people who are on call have paged themselves to have an excuse to leave a meeting – that may or may not have been me at some point :)

Last weekend, at FOSDEM 2023, I watched a Lightning Talk by Frank Vanbever titled “Lua for the Lazy C developer”. I had recently suggested at work that we should be using Lua to script the behavior of some systems which are written in Go, so the talk strongly resonated with me.

Lua is an ideal scripting language for embedding into other programs because it is small and provides excellent bindings in both directions – Lua code can call native code, and vice versa. Because Go has good hash tables as part of the language, using Lua as a container for your hash tables is probably less interesting than from C though.

During the talk, I tried porting the “Hello World” example to Go as the native language. It turns out that Shopify published a pure-Go reimplementation of the Lua interpreter that is byte code compatible with the original C implementation! They use this for scripting the behavior (ha!) of their load testing tools. The package is at github.com/Shopify/go-lua.

It turns out that the example from the talk translates 1:1 to Go and Lua:

package main

import lua "github.com/Shopify/go-lua"

func main() {
	l := lua.NewState()
	lua.OpenLibraries(l)
	l.Global("print")
	l.PushString("Hello World!\n")
	l.Call(1, 0)
}

And it does exactly what you would expect:

$ go build .
$ ./luatest 
Hello World!

The full example is available as a GitHub Gist.

I have been a pkgsrc developer for several years. For what it’s worth, I think pkgsrc is wonderful: a large selection of third-party software, packaged so that it is easy to install with a single command – either building everything from source, or relying on binary packages. pkgsrc supports dozens of OSes – not just NetBSD but also other BSDs, macOS, Linux, Illumos and more.

On the other hand, unfortunately, pkgsrc and NetBSD in general are suffering from what I would call a loss of mindshare. When I joined the NetBSD Foundation as a developer, I had the impression that NetBSD had more users and community than OpenBSD or, say, Dragonfly. In recent years however, it seems to me that people have more or less forgotten about NetBSD and pkgsrc.

Here is where you may come in

Here is a simple idea that occurred to me a while ago and that I finally am getting around to writing up, now that I am sitting in the train to FOSDEM 2023:

These days, a lot of upstream software has a manual with a section on installation that does not give instructions for actually building it. (It seems like building from source is so 1995, or something.) Instead, it goes roughly like this:

If you are using a Mac or a Linux/x86_64 machine, see our own binary packages here. Or use distro packages:

For Debian, run apt-get install somepackage.

For Fedora Linux, run some yum command.

etc. etc.

There is typically a long list of install commands for a bunch of Linux distributions and OSes. pkgsrc is almost never mentioned.

So if you are looking for a simple way of helping out pkgsrc and NetBSD, look for the README of your favorite Open Source tools and add a section for installing from pkgsrc. Typically, for a package from pkgsrc itself, the simplest is to add instructions for using pkgin:

$ pkgin install somepackage

For packages in pkgsrc-wip, you could first ask on the mailing list for an import so that there may be binary packages in the future :) Then, give the typical instructions for installing from source:

$ cd /usr/pkgsrc/wip/somepackage
$ make package-install

I have created a few pull requests for such changes in the past, but I think we need a lot more of that!

It took me quite a while to realize that I have been here before.

When Google+ (the greatest social network I have used, by the way) was killed, somebody spun up Pluspora as a refuge. It was a Pod of something called diaspora. It was nice in the beginning, then gradually I interacted with it less – since, TBH, there wasn’t much content, and I also didn’t post much. Eventually, the person running the Pod died, and their family ended up switching it off.

So when that guy bought Twitter and proceeded to run it into the ground at unprecedented speed, the number of Twitter postings saying “find me on Mastodon @x@y.z” multiplied on my timeline.

Also, at work, we occasionally had a moment where we all shared our gratitude not to work for Twitter. But I digress.

Being a NetBSD dev, it seemed natural to me to register an account on mastodon.sdf.org. SDF was founded as a Public Unix System, giving out free shell accounts to people. They have been running on NetBSD for many years and form a valuable part of the NetBSD community.

The beginning was rough: The SDF Mastodon server had surpassed 15,000 users, just days after breaking through the 10,000 mark. Service was slow, there were lots of errors, and it was generally not super pleasant. However, within a few days, the SDF admins started adding a LOT more hardware to the service, and these days, latency and functionality are top-notch. I think instead of paying $8 for a blue checkmark, that money is better spent with a recurring SDF donation!

The Fediverse

I alluded to this earlier, but diaspora and Mastodon are part of the Fediverse, so they federate. Just like in email, you can follow people from other servers, even using different software. For instance, Mastodon has a 500-character limit for posts, but you could follow someone using Plume for blogging, and their full blog posts would appear right on your timeline. Or I suppose you could follow someone’s PeerTube channel and have their videos appear on your timeline.

This is also how I eventually realized “Mastodon” and “diaspora” are really the same network: in the federated (global) timeline, a number of bots and people I already knew appeared.

Coming over

If you are looking to come over to Mastodon, you probably want to do the following things:

1. Create an account on some server. It’s nice if you like the “theme” or the other people on the same server, since then you can look at the list of all public local posts when you are looking for something to read.
2. Add your new address to your Twitter account – name, bio, link, all are fine.
3. Head over to https://fedifinder.glitch.me and let it find the Fediverse accounts for all the folks you follow on Twitter. You can download a CSV and import it in the Mastodon settings page, making you follow everyone automatically.

Side note

diaspora still exists. Hilariously, if you follow the “Sign up now!” link on their homepage, you eventually arrive at https://diaspora.fediverse.observer/go&software=diaspora, which lists … no open Pods for signup.