In the era of traditional social media, leaving a platform meant leaving your audience behind. On centralized walled gardens, user data, follower networks, and content archives are locked inside proprietary servers. If a platform changes its algorithm, hikes subscription fees, or bans an account, creators and business owners have no recourse. The cost of exit is absolute: total audience destruction.
The primary promise of the open social web has always been different. Decoupling identity from infrastructure gives creators true digital sovereignty—the guarantee that your online business, publishing archive, and follower connections belong to you, not to a platform operator.
However, in practice, migrating your digital life across the Fediverse has remained frustratingly complex. While protocols like ActivityPub allow users to shift followers from one instance to another, historical posts, likes, direct messages, and media uploads often stay stranded on the old server. If an instance suddenly shuts down or experiences severe moderation conflict, users face partial or total data loss.
To address this challenge, the World Wide Web Consortium (W3C) formally re-chartered the Social Web Working Group (2026–2028). At the top of its agenda is a standard designed to make server migration seamless: LOLA (Live, Online Portability).
In this article, we examine how the LOLA specification works, why seamless account portability is the missing pillar of the open web, and how it compares to alternative models like the AT Protocol's Personal Data Servers (PDS).
1. The Migration Bottleneck in Today's Fediverse
To understand why LOLA is necessary, we must first look at how account migration currently operates across ActivityPub platforms like Mastodon, Pixelfed, and Sharkey.
Currently, moving an account relies on a basic HTTP redirect mechanism combined with follower alias notifications:
- Alias Setup: A user creates a new account on Destination Server B and sets an alias pointing to their old account on Source Server A.
- Move Command: The user issues a
Moveactivity from Source Server A pointing to Destination Server B. - Follower Notification: Source Server A broadcasts an ActivityPub
Moveactivity to all remote servers where the user’s followers reside. Receiving servers update their local databases to re-follow the new account handle.
While this mechanism succeeds at transferring follower connections, it leaves severe gaps:
- Stranded Content Archives: Posts, articles, uploaded media, bookmarks, and private threads remain locked on Source Server A. Remote servers do not automatically re-attribute past interactions to the new account.
- Server Dependency: The migration process requires Source Server A to remain fully operational and online during the transition. If an admin abruptly takes a server offline, users lose the ability to trigger
Moveactivities altogether. - Broken Web Connections: Inbound links, web mentions, and external integrations targeting old profile URLs break once Source Server A disappears.
For businesses, journalists, and independent media organizations relying on the open web for customer acquisition and distribution, these friction points represent unacceptable operational risk.
2. Enter W3C's Social Web Working Group
Recognizing that protocol fragmentation and migration barriers hinder mainstream adoption, the W3C launched a newly chartered Social Web Working Group with an official mandate spanning through January 2028.
Unlike informal community incubator groups, a formal W3C Working Group has the authority to refine, update, and elevate draft specifications into official W3C Recommendations—the highest technical standard on the web (on par with HTML5, CSS, and HTTP specifications).
The Working Group's charter prioritizes several key areas for ActivityPub and Activity Streams:
- Clarifying Implementation Ambiguities: Resolving core protocol gaps in server-to-server delivery, inbox forwarding, and payload verification.
- Standardizing Data Portability (LOLA): Integrating the Live, Online Portability protocol into the core standards track.
- Enhancing Trust & Safety: Standardizing instance moderation signals, blocklist synchronization, and identity verification mechanisms.
By establishing an official standards track for portability, the W3C aims to shift account migration from a platform-specific workaround to a universally supported protocol primitive.
3. How LOLA Works Under the Hood
The LOLA (Live, Online Portability) specification shifts the paradigm of account migration from push-based follower updates to full-state cryptographic identity transfer.
Instead of treating an account as a simple database row tied to a specific domain name, LOLA treats a social profile as a portable data object that can be securely mirrored, verified, and re-hosted across independent nodes.
The LOLA workflow involves four distinct synchronization phases:
Phase 1: Authenticated Data Exchange
The user authenticates with both Source Server A and Destination Server B. Server B establishes an encrypted API channel with Server A to request a complete account manifest, including outbox activities, media assets, interaction graphs, and profile metadata.
Phase 2: Cryptographic Identity Binding
To prevent spoofing or unauthorized account hijacking, LOLA incorporates public-key cryptographic proofs. The user signs the migration request using cryptographic keys associated with their original identity. Server B verifies these signatures before accepting the inbound profile data.
Phase 3: Outbox Re-indexing and Media Proxying
Server B ingests the user's historical outbox, re-indexing posts with original timestamps and canonical identifiers. Media assets are transferred to Server B's storage layer or served via verified content delivery endpoints, preserving embedded images and attachments within past posts.
Phase 4: WebFinger Forwarding and Tombstoning
Once data transfer is validated, Server A generates an immutable WebFinger redirect (301 Moved Permanently) and a cryptographic "tombstone" activity. Any incoming request for @user@serverA.com automatically resolves to @user@serverB.com, preserving historical inbound web links and protocol traffic.
4. Comparing Portability Models: ActivityPub (LOLA) vs. AT Protocol (PDS)
As decentralized social architecture matures, two distinct philosophies have emerged regarding identity and data portability: the ActivityPub / LOLA approach and the AT Protocol (Bluesky) approach.
| Architectural Feature | ActivityPub + LOLA (Fediverse) | AT Protocol + PDS (Atmosphere) |
|---|---|---|
| Primary Identity Anchor | Domain Name + WebFinger (@user@domain.com) |
Decentralized Identifier (did:plc or did:web) |
| Data Storage Location | Server database (migrated between hosts via LOLA) | Independent Personal Data Server (PDS) |
| Migration Mechanism | Live server-to-server state transfer & redirect | Pointing DID routing record to a new PDS endpoint |
| Governance Body | Open Standards Consortium (W3C) | Open Source / Single Corporate Brand (Bluesky PBC) |
| Historical Post Continuity | Re-indexed by target server via cryptographic proof | Remotely hosted on PDS; indexing layers update references |
In our previous analysis on AT Protocol trademark governance, we highlighted how Bluesky achieves account portability by separating the identity layer (DID) from the hosting server (PDS). Shifting servers in AT Protocol is fundamentally a DNS/routing update rather than a massive data migration.
Conversely, ActivityPub was originally built around domain-centric identities. LOLA bridges this gap by enabling federated servers to execute live state transfers without abandoning the human-readable domain structure that defines the Fediverse.
5. Why Portability Matters for Independent Businesses and Creators
For digital creators, media outlets, and businesses, platform lock-in is a financial vulnerability. When your audience exists solely inside a platform's database, your business is subject to single-point-of-failure risks:
- Policy Volatility: Sudden changes in terms of service or content monetization can destroy revenue streams overnight.
- Infrastructure Failure: Server outages, host bankruptcies, or improper admin management can wipe out years of audience building.
- Geographic and Legal Compliance: As regional data regulations evolve (such as the EU Digital Markets Act or GDPR data portability mandates), businesses need the flexibility to migrate server infrastructure across jurisdictions without losing customer contact points.
By standardizing LOLA, the W3C is creating a legal and technical framework where departure is a built-in rights guarantee. If a server administrator raises hosting fees, enforces arbitrary rules, or fails to maintain server uptime, a creator can migrate their entire digital footprint to a new provider in minutes.
Conclusion: Building a Web Where Departure Is a Feature
True digital freedom requires more than the ability to join a network—it requires the right to leave.
As the W3C Social Web Working Group advances the LOLA specification toward formal recommendation status, the open web moves closer to fulfilling its founding promise: a decentralized internet where users control their identity, own their relationships, and carry their digital lives wherever they choose.
For businesses entering the Fediverse today, evaluating server hosts based on data export standards and protocol compliance is no longer an afterthought—it is the cornerstone of long-term digital sovereignty.
Sources and References
- W3C Social Web Working Group Charter (2026–2028): https://www.w3.org/2026/01/social-web-wg-charter.html
- W3C ActivityPub Recommendation: https://www.w3.org/TR/activitypub/
- SWICG LOLA (Live Online Portability) Specification Draft: https://swicg.github.io/activitypub-data-portability/lola.html
- W3C ActivityPub Code & Issue Repository: https://github.com/w3c/activitypub
- SWICG ActivityPub Data Portability Repository: https://github.com/swicg/activitypub-data-portability
Comments
Loading comments from the Open Web...