Matt Ball's Profile Photo

Matt Ball

Identity in the Fediverse

I (like many people) have been paying more and more attention to distributed social networks over the past several weeks. For the uninitiated, these networks (hereafter referred to as “the Fediverse”) are individual instances running software which communicate with each other over standard protocols (mostly ActivityPub). A user on one instance can follow and interact with users on other instances in a mostly-transparent way, somewhat similarly to e-mail.

The general philosophy, I think, seems sound: by decentralizing things, you reduce the influence — and potential damage — of any one entity. If a particular Mastodon instance is behaving in bad faith, users can stop supporting that instance and migrate to a different one while still participating in the broader federated network.

But one thing that keeps eating at me is the lack of a persistent identity across the Fediverse. Sure, a user can switch to using a different instance, but that involves creating a new account and leaving all of their followers behind (it’s not uncommon to see “I’m moving to new instance, so re-follow me at name@new-instance” posts, which really isn’t ideal). Your identity in the Fediverse is inextricably tied to a specific instance, with no way to transparently migrate to a new host.

The structure of the Fediverse also encourages holding multiple accounts across different types of software. For example, Mastodon is generally optimized for Twitter-style microblogging, while PixelFed is geared towards Instagram-style image sharing, and so on. If one wants to microblog and post photos, it seems like the best bet would be to microblog on a Mastodon instance and share photos on a PixelFed instance. But if you do that, what should interested followers do? Follow you twice? Throw a PeerTube account into the mix for a third follow. And so on.

To be fair, this is true of the traditional, centralized social networks too; if you want to follow someone’s tweets and photos, you need to independently follow them on Twitter and on Instagram. But the cross-network interoperability of the Fediverse makes this feel more awkward to me. If I want to follow someone on Twitter and on Instagram, I need to separately follow them from both my Twitter and Instagram accounts. But for federated networks, I can theoretically follow someone’s microblog, photos, videos, and more from a single account. And if I have multiple accounts across the Fediverse, from which account should I follow others? If I want to follow someone’s content on FunkWhale (where, in this hypothetical example, I don’t have an account), which of my N accounts makes sense to follow from?

Philosophically, I think probably has the best story for persistent identity, encouraging people to put their content behind a domain name which they own. doesn’t federate over ActivityPub (by design), but the general idea seems applicable to federated content.

Technically, there’s nothing to stop someone from hosting their own single-user Mastodon instance on their own server, resulting in a handle which other Fediverse users can follow. But, doing so brings us back to the “use the best tool for the job” sentiment behind using (for example) Mastodon and PixelFed simultaneously — there’s no precedent or pattern (that I’ve found, at least) for a single username sitting in front of multiple underlying ActivityPub implementations.

That feels like what I’m really after here: a single ActivityPub-federating endpoint which consolidates an arbitrary number of underlying services or instances. This would hypothetically let us:

  1. Present a single, unified identity across the Fediverse
  2. Post different types of content using the best tool for the job
  3. View the content posted by people we follow in a UI which is ideal for the content in question

Maybe someone will build such a thing someday, as (or if) the Fediverse continues to grow.

Or maybe I’m just overthinking all of this. The fact that I originally intended this to be a ~250 character note means that’s probably the case…