How LOLA Account Portability Actually Works
This article is part of a series: A Testbed for ActivityPub Account Portability
If you are interested in decentralized systems, interoperability, or building in the Fediverse, this series is for you.
In the first part of this series, I gave a brief introduction to ActivityPub, Fediverse, LOLA spec and the development of our ActivityPub-Testbed and discussed the problem that account portability tries to solve.
We, the users, build stories across multiple social platforms. We accumulate a rich history of posts, conversations, relationships, and a sense of continuity over the years.
In the Fediverse, that continuity still depends on policies, maintenance, and various factors beyond the users’ control. If a server changes, shuts down, or for whatever reason users decide to migrate, transferring our information is still somewhat complicated.
This article delves into the process of how we will try to solve it using LOLA spec and our Testbed.
LOLA is a draft specification for ActivityPub account portability created by Lisa Dusseault within SWICG. It provides the reference point for the work we are doing in the ActivityPub-Testbed.
If account portability is going to work in a live, decentralized network, it cannot just be an abstract promise. It has to become a protocol. It has to define what servers discover, what users approve, what gets copied, and what happens afterward. That is the role of LOLA.
LOLA does not treat portability as a one-click export, nor as a magical replacement of one account with another. Instead, it describes a staged interaction between three parties: the user, the source server, and the destination server.
The Three Parties Involved in a LOLA Transfer
At the center of a LOLA portability flow is the user who wants to migrate their account data from one server to another. But the user isn’t acting alone. The two servers involved in the process must cooperate, each with different responsibilities.
The source server is the server that currently holds the account and its data. It is the place where the user already has an identity, content, social relationships, and history.
The destination server is the server the user wants to move to. It is responsible for initiating the transfer, receiving the copied data, and recreating it in a way that makes sense locally.
The user remains the one who authorizes the process and decides whether to continue it. This is really important. LOLA is not designed as a server-to-server transfer that happens invisibly in the background without user involvement. It is designed around user intent and user consent.
In LOLA, the importance of the user is emphasized throughout the entire process, and we try to make this as explicit as possible in its implementation on the Testbed. Account portability must be a transfer process controlled at all times by the user.
Portability Starts With Discovery
Before one server can request anything from another, it has to discover whether portability is even supported.
This is the first major phase in LOLA: discovery and authorization.
The destination server needs to learn enough about the source server to begin a valid portability flow. That means it has to find the source server’s portability-related OAuth surface and understand how to request the right kind of access. Portability begins not with copying data, but with finding the correct protocol entry points.
This is a meaningful step in a federated environment. Different servers may expose different capabilities, different levels of support, or different implementation choices. A destination server cannot safely assume that every ActivityPub server behaves the same way, or that every server exposes account data in a portability-aware form.
Discovery is what turns portability from guesswork into interoperability.
Why OAuth Is Part of the Flow
Once discovery succeeds, the next part is authorization. This is where OAuth 2.0 enters the flow.
The destination server is not supposed to quietly collect account data from the source server on its own. It needs the user’s explicit approval. OAuth provides the mechanism for that approval to happen. The destination server directs the user to the source server, the user authenticates there, and the user grants permission for the destination to access portability-related data.
OAuth is the permission layer that makes the rest of the protocol possible.
LOLA builds on top of OAuth because account portability can involve more than public data. Depending on the server and the user’s account, portability may involve posts that are not public, liked objects, block lists, or other data that should not simply be exposed to any third party that knows an account URL.
So the goal is not just “can the destination fetch data?” The goal is “can the destination fetch the right data, from the right account, with the user’s consent, under a bounded scope?”
OAuth also matters for trust between services. The source needs a way to distinguish a legitimate requesting service from an attacker pretending to be one, and the authorization flow helps establish that boundary before any protected data is made available.
Get Aarón Ayerdis Espinoza’s stories in your inbox
Join Medium for free to get updates from this writer.
That is why portability authorization matters so much. It is not just a login step. It is the security boundary around the transfer itself.
How OAuth Flow Hands Off Authorization
User approval at the source server is not the end of the process. It is the point where the destination gains the ability to continue the flow securely.
After the user approves the request, the source server redirects back to the destination with an authorization result. The destination can then validate the callback, confirm the request state, and exchange the authorization for an access token.
That token is what the destination uses to start making authentication requests back to the server.
This design is important because portability in LOLA is not just a browser redirect. It is a live server-to-server interaction that continues after the user has given consent. The callback hands the flow back to the destination, and the token exchange turns that approved request into authorized access.
This implementation approach is much more realistic for Fediverse portability. Account data can be large. It can be paginated. It can include different kinds of objects and collections. It may require retries, moderation decisions, or staged review. A proper portability protocol needs a controlled way to continue the transfer after the user consents, and that is exactly what this model provides.
Copying Data Is Its Own Phase
After discovery and authorization comes the second major LOLA phase: fetching and saving data.
This is where the destination server starts asking the source for the data that makes up the user’s account history.
That data is not limited to one thing. It may include content the user authored, collections related to following or blocking, liked content, etc. The specification treats these as distinct parts of the account, not as one undifferentiated export blob.
That distinction is important because not all kinds of account data behave the same way, and not all of them should be handled identically.
A user’s content is not the same as a list of followed accounts. A list of followed accounts is not the same as followers. A block list is not the same as public profile information. Some data is core to recreating the user’s presence. Some data is privacy-sensitive. Some data can be copied directly. Some data needs to be interpreted more carefully at the destination.
LOLA takes that complexity seriously.
Rather than pretend that portability is just a matter of replaying everything a user ever did, the specification leans toward copying the current state that matters most and making that state available through clear, structured surfaces.
Best Effort Matters More Than Perfect Duplication
Another important idea behind LOLA is that portability is a best-effort process, not a guarantee of perfect duplication.
It is an honest reflection of the network it is trying to serve.
Fediverse servers do not all support the same content types, moderation models, metadata fields, storage systems, or user expectations. Even when two servers both support ActivityPub, they may differ in how they represent or preserve certain aspects of user data. Some may support richer object types. Some may not. Some may preserve more metadata.
LOLA takes a more practical position. Preserve what matters. Make the transfer understandable. Give the user a way to review the result. Accept that some degradation may happen, but structure the protocol well enough that the result is still meaningful and useful.
This is especially important in a decentralized ecosystem. Interoperability often depends not on making every server identical, but on creating a process that lets different systems cooperate honestly despite their differences.
What Happens After the Copy
The final major LOLA phase is optional follow-up work.
This is where portability begins to overlap with account movement in the public sense.
After a user has copied their data and confirmed the result, they may choose to do more. They may want the source server to notify followers of a move. They may want the source server to mark the account as moved. They may want old content to redirect toward its new location. They may want the source account to enter a different lifecycle state while still preserving some continuity.
Why the ActivityPub-Testbed Matters Here
All of this can sound abstract until it is grounded in an implementation.
That is part of what makes the ActivityPub-Testbed valuable. It is not just a place to discuss portability as an idea. It is a place to explore what a LOLA-aware environment actually needs to expose, validate, and test.
The work is not simply about adding one OAuth screen or one export endpoint. It is about shaping a source server that can advertise portability correctly, expose meaningful migration data, distinguish public access from portability access, and eventually support the broader portability story with greater fidelity.
Just as importantly, it is also about understanding the destination side of the interaction. A real portability flow is not complete until both sides of the exchange make sense.
