ActivityPub and account portability
The Fediverse (Mastodon and other connected servers supporting ActivityPub) was designed to be a social network running on many independent servers, allowing individuals to participate in online social life without being tied to a platform. This foundational promise, however, remains incomplete without true account portability to give users the freedom to move accounts.
A social account can be used to maintain friendships, collaborate professionally, pursue hobbies, share information, promote one’s preferred policies or politicians, and so much more. All of the posts and replies in a social account build a very personal history, holding years of images, messages, memories, relationships, and a sense of evolving identity and purpose.
Although the Fediverse offers choice of where to create an account (like email does) and still connect, every account must live on a server, and that server is not permanent. Often hosted by a friend or former colleague, one’s Fediverse server can be shut down in an orderly way, change policies, defederate from other servers, be defederated, or simply suddenly disappear. If these server changes prompt a user to move their account, they face the difficult reality that their posts, followers, and entire digital social life may not move with them.
For the Fediverse’s freedom from centralized control to continue to work in a constantly moving world, Fediverse account portability cannot be an afterthought; it must be a first-class, foundational capability. Users need a reliable, non-workaround solution to move their content, accounts, and relationships from one server to another.
Fortunately, this isn’t hard, at least technically. Since in the Fediverse servers request data from each other, most of the data requests to move an account to another server are already supported. This interoperability is defined mostly by ActivityPub, an open standard developed by the World Wide Web Consortium (W3C). ActivityPub acts as the shared language, defining common structures for users (actors), content publication (outboxes), notifications and messages (inboxes), and social actions like following and sharing.
The few missing pieces for safe and reliable server-to-server account transfer require a bit of agreement on specifics:
- How can the requesting server use OAuth to gain full access to private account information? What exactly is the OAuth URL and what data access scope can be requested?
- How is private information conveyed? What ActivityStream collections hold private information and what are their URLs?
- How are references across servers handled when the object referred to moves?
Answering these questions is why the LOLA Portability (Live, On-Line Account Portability ) draft specification was developed. LOLA defines a process where a destination server can request and copy account data directly from a source server, with the user’s authorization, while both systems remain online. The specification is being developed within the W3C’s Social Web Working Group.
LOLA organizes account portability into three structured phases:
-
Discovery and Authorization
The destination server confirms the source server supports portability and what its URLs are. The user is redirected to the source server to authenticate and explicitly approve the data transfer using OAuth 2.0 and an appropriate scope that grants just the right permissions. -
Fetching and Saving Data
Once authorized, the destination server requests and recreates the user’s key collections, such as posts, following lists, liked content, and block lists. Crucially, this is designed as a copy, not a destructive move, allowing the user to verify the result before making further decisions. -
Testing and Finalizing Phase
After the copy is successful, the user can choose to notify followers of the move, redirect links to old content, and close down their old account, when they are ready.
The Data Transfer Initiative supports this work by contributing to the authoring of LOLA and of a testbed for LOLA implementers to test against. This supports our overall mission of improving the availability and functionality of data portability generally, by showcasing an architecture that works well even under the difficulties of federation, linked content, and private as well as public information. For a deeper dive, I have written the start of a series of articles on the testbed and the technical pieces of LOLA – check it out.