There are two ecosystems out there in the decentralized social networking space these days. There's the Fediverse, built on top of the ActivityPub protocol, and there's now a parallel set of software popping up around Bluesky and the AT Protocol (or "ATProto"). The Fediverse now has PeerTube (a YouTube-like service), Pixelfed (like Instagram), and Loops (like TikTok). In the ATProto world, there are apps like Pinksky (like Instagram) and Skylight (like TikTok).

ActivityPub and atproto have two very different architectures, and much has been made recently about just how decentralized Bluesky really is. It's worth reading up on this to understand the tradeoffs made in each, but today I'd like to dig into the two ecosystems from a different angle. Specifically: when expanding beyond Mastodon or Bluesky's Twitter-style interaction model, what does the user experience look like?

As currently implemented, apps built on ATProto have a big advantage over apps built on ActivityPub for initial user onboarding. When you log into Pinksky, you're logging in with your existing Bluesky account, and as a result you'll see posts from the people you're following right from the start. They'll be filtered to only include posts that make sense in the context of an Instagram interface (it's built to display photos, after all) but you'll already have a feed to browse. By constrast, you can't log into Pixelfed from a Mastodon account - you need to make an account on a Pixelfed server first. And you won't be following anyone from that new Pixelfed account at the start, so you'll see an empty feed!

This is not an inevitable consequence of building on top of ActivityPub, but it is a consequence of the way that most ActivityPub applications are written these days. ActivityPub has two protocol variants specified: one for server-to-server (S2S) communications, and one for client-to-server (C2S). The S2S variant of ActivityPub is widely used by applications like Mastodon and Pixelfed to enable interoperability between servers. The C2S variant, by contrast, has gone largely unused, with each application instead defining its own API for its clients to communicate with its servers. (Or, for applications that are sufficiently similar to Mastodon, reusing the Mastodon API, since there are a bunch of Mastodon clients out there.)

The Mastodon API (and the Mastodon server) is tightly focused on microblogging. It wouldn't make a lot of sense to build a PeerTube client on the Mastodon API, or a Pixelfed client on the PeerTube API, and their servers