Fixing Mastodon biggest UX issues

Mastodon is a decentralized social media platform based on the ActivityPub protocol, with instances communicating with each other. Basically, it's like many "small Twitters" communicating with one another: even though Mastodon wants to be a space where any voice can be heard, its structure is quite archaic and follows the traditional centralized data hierarchy.

The way the ActivityPub protocol is structured creates some UX issues:

In this article, you'll see that ATProto solves all the shortcomings ActivityPub has, and that Mastodon should run on ATProto instead of ActivityPub, which isn't suited for small instances or true data ownership.

How can people remember where they signed up?

With ATProto, your account and handle work across the whole Atmosphere, not just on Bluesky. This means users can use any app (blogging, reviewing films, hosting websites...) with a single account. They can also use any client or microblogging app that integrates the Bluesky lexicon.

I personally use Witchsky.app for both of my accounts (a private one hosted on my own PDS¹, and matlfb.com hosted on Eurosky). This way, I have both accounts logged into the same page and can switch between them in two clicks. On Mastodon, I also have a private account and a public one, but unlike Witchsky, Mastodon instances don't support multiple accounts, so I'm forced to open two separate tabs of the exact same interface.

If Mastodon ran on ATProto, users could log into any other Mastodon client and also add several accounts within a single interface.

How can users migrate their entire data?

ActivityPub does support account migration through Mastodon's native movedTo mechanism, but it only transfers your followers and following list, never your posts. Every Fediverse app has to implement this move feature the way Mastodon did, and there's still no way to bring your post history along when you switch instances.

On the Atmosphere, you can simply move your entire account from your PDS (essentially a backpack holding all your ATProto data) to another one, in three clicks.

If Mastodon ran on the Atmosphere with PDS support, people registering on Mastodon would have handles like user.mastodon.social. So if users wanted to move from a Mastodon PDS to another one, they could set up the migration via PDSMoover and simply indicate the target PDS. And remember, an Atmosphere account also stores data from any ATProto app you use. So users wouldn't just migrate their Mastodon data, but all of their data across every Atmosphere app as well. All from one website, in under five minutes.

How can they try other apps?

If Mastodon users want to try Pixelfed or Flipboard (also built on ActivityPub), they have no choice but to create another account and start from scratch. It's also a hassle: you have to remember yet another account and which instance you signed up on.

As I mentioned earlier, a single ATProto account works across the entire Atmosphere. That means people can try any app while their data stays under one handle. If Pixelfed were part of the Atmosphere, users could simply log in with their Mastodon handle and retrieve their Mastodon followers, likes, and possibly even posts containing pictures thanks to the modularity of lexicons. Whether an app actually surfaces that data is ultimately up to its developer, since each app chooses which lexicons it reads and displays, but the data itself is already there under one account instead of locked in a separate silo. Mastodon could also display Bluesky posts and activity.

Who owns the data of Mastodon users?

On ActivityPub, user data is owned by the instance administrator. They can decide to delete or suspend your account at any time, since they own the database. In some cases, admins have shut down an entire instance without warning its users, who then saw their accounts deleted and lost everything.

On ATProto, the data is yours. If you want it stored by Bluesky, you can. If you want it stored by pckt.blog, you can. If you want to self-host your own PDS and store your data there, you can do that too (it's actually very lightweight and easy). And more importantly, if you set up a backup with pdsmoover in advance, you can restore your account with your rotation key even if your PDS provider shuts down the servers, which is impossible with ActivityPub.

What's more, all app data is stored in your Atmosphere account. Users can view their app data through records called lexicons. A lexicon groups together all kinds of records (likes, follows, posts...) belonging to an app (called a Collection). If you want to check your own data and records, you can use pds.ls and search for your account and you'll see every app you've interacted with.

If Mastodon ran on the Atmosphere, people could view and delete their data in three clicks. Want to delete all your follows? You can. Want to delete all your likes from Bluesky? You can do that too. You truly are in control of your data.

One caveat worth mentioning: your content's visibility still depends on which relay and AppView index it, and today most of that infrastructure is run by Bluesky. But alternative AppViews like Blacksky (and soon Eurosky) let you route around Bluesky's default stack while staying on the same protocol.

Thanks for reading! I wanted to use these few examples to show you how powerful ATProto is. I believe Mastodon has everything to gain by switching protocols, especially once permissioned data is released. Given how big Mastodon is, it could launch its own relay and AppView to become fully independent from Bluesky's infrastructure, similar to what Eurosky is doing with mu.social.

We could talk a lot more about the Atmosphere's advantages in discoverability and scalability, which Mastodon currently lacks, but that would take much longer to explain.

If you like my work, you can follow me here, on Bluesky (same handle either way), or on Mastodon, even though I'm less active there these days.