Understanding Account Portability in the Fediverse
If you’re interested in decentralized systems, interoperability, or building in the Fediverse, this article is for you.
An account — regardless of its size or visibility — carries something more than just data. It holds time, memories, relationships, and a sense of identity that builds gradually over the years.
Many of us grew up alongside social platforms, and some still have our very first accounts — sometimes with usernames we’d rather forget — but they represent something real: a timeline of who we were, how we’ve changed, and the connections we’ve made along the way. These spaces have allowed us to witness not only our own growth, but also the perspectives and lives of others, so it’s natural that we develop a certain level of personal attachment to them.
This is not about romanticizing social media, but about recognizing that, when used well, these platforms become part of our personal history. And yet, in the Fediverse — a space designed around user control and decentralization — there is still a gap that needs to be addressed.
A user’s account ultimately lives on a specific server. And that server is not permanent. It can shut down. It can change its policies. It can defederate from others. It can simply stop existing.
When that happens, the user is faced with a difficult reality: their posts, their followers, their interactions — their digital social life — may not move with them. The Fediverse promises freedom from centralized control. But without a true account portability implementation, that promise remains incomplete.
As developers, we understand the complexity behind running and maintaining these systems. Servers require time, resources, and constant effort. And just as they can be created, they can also disappear. But precisely because of this, portability shouldn’t be an afterthought — it should be part of the foundation. Users should have a reliable way to move their accounts, their content, and their relationships from one server to another — not as a workaround, but as a first-class capability of the network.
This is where the ActivityPub Testbed — and the LOLA specification — come in. They are part of an ongoing effort to explore and validate how account portability can work in practice, helping turn an important idea within the Fediverse into something tangible, testable, and eventually interoperable.
What the Fediverse and ActivityPub are
Before going deeper into account portability, it helps to understand the environment in which this problem exists. The Fediverse and ActivityPub are not just technologies, but foundational concepts that shape how this ecosystem works — how users connect, how content moves, and how different platforms interact with each other.
The Fediverse can be understood as a network of independently operated servers that communicate with one another using shared, open protocols. Instead of a single platform owning all user accounts and data, responsibility is distributed across many servers, each run by different communities, organizations, or individuals. Despite this distribution, users are still able to interact across servers — following each other, sharing content, and participating in conversations — as if they were part of a single network.
This is made possible by ActivityPub.
Get Aarón Ayerdis Espinoza’s stories in your inbox
Join Medium for free to get updates from this writer.
ActivityPub is an open standard developed by the World Wide Web Consortium (W3C) that defines how these servers communicate. It provides a common structure for representing users (actors), publishing content (through outboxes), receiving interactions (through inboxes), and expressing social actions such as following, liking, or sharing. In practice, it acts as the shared language that allows different platforms in the Fediverse to understand each other.
Because of this, a user on one server can follow someone on another, and a post created in one place can be seen and interacted with from many others. ActivityPub is what transforms a collection of independent servers into a connected network.
This model introduces a different way of thinking about online presence. Instead of being tied to a single platform, users exist within a broader network where identity and interaction can span across multiple servers. The Fediverse provides the structure, and ActivityPub provides the rules that make that structure interoperable.
Account portability builds on top of this foundation. While ActivityPub enables communication between servers, portability focuses on continuity between them — extending the same principles of openness and interoperability to the user’s data, relationships, and history.
What LOLA Is and Why It Matters
Account portability in the Fediverse is not just a conceptual goal — it requires a shared understanding of how servers can safely and reliably transfer account data between each other. This is where LOLA comes in.
LOLA is a draft specification that defines how a user can move their account from one ActivityPub server to another in a live, server-to-server interaction. Instead of relying on static exports or manual reconstruction, LOLA describes a process where a destination server can request account data directly from a source server, with the user’s explicit authorization, while both systems remain online.
The specification is being developed within the Social Web Incubator Community Group (SWICG), and is currently at version 0.2. It is still evolving, as most protocols do at this stage, but it already provides a clear structure for how portability can work in practice. The work is led by Lisa Dusseault, CTO at the Data Transfer Initiative, whose authorship and direction of the specification have been central to shaping how portability is approached within the ActivityPub ecosystem. As part of this effort, I work within the Data Transfer Initiative on the implementation side, contributing to the development of the ActivityPub Testbed and its codebase as a practical environment for exploring these ideas.
At a high level, LOLA organizes account portability into three phases.
The first phase focuses on discovery and authorization. A destination server identifies whether a source server supports portability and discovers how to request access. The user is then redirected to the source server, where they authenticate and explicitly approve the data transfer. This step is built on OAuth 2.0, which acts as the security layer ensuring that any data access happens with the user’s consent.
The second phase is centered on fetching and saving data. Once authorization is granted, the destination server can request the user’s content and related collections — such as posts, following lists, liked content, or block lists — and recreate them locally. Importantly, this process is designed as a copy, not a destructive move, allowing the user to verify the result before making any further decisions.
The third phase is optional and happens asynchronously. After the data has been successfully copied, the user may choose to notify followers of the move, redirect old content, or transition their original account into a different state. This phase reflects the reality that migration is not just a technical operation, but also a user-driven decision that may happen over time.
One of the most important aspects of LOLA is its design philosophy. Rather than aiming for perfect duplication, the specification embraces a best-effort approach to migration. Differences between servers — in features, formats, or capabilities — mean that a fully identical transfer is not always possible. Instead, LOLA focuses on preserving what matters most: continuity of content, relationships, and identity, while allowing implementations to make practical decisions where needed.
It’s also important to understand that LOLA is not limited to a single technical component. While OAuth 2.0 provides the authorization mechanism, the specification goes further — defining how data is discovered, how collections are accessed, how content is represented, and how migration flows are structured from the user’s perspective. In that sense, OAuth is the entry point, but LOLA defines the broader architecture that makes portability possible.
Ultimately, LOLA provides a shared framework for thinking about account portability in the Fediverse. It translates an idea — that users should be able to move across servers — into a set of concrete interactions that can be implemented, tested, and improved over time. The ActivityPub Testbed builds on top of this work by providing a real environment where these interactions can be explored in practice.
