Data and Account Portability on the Social Web

FediForum 2025

Definitions

Q: How many Identity specifications experts does it take to change a lightbulb?�

A: Define "lightbulb".

​

​

Definitions

Define "social web"?

Well, everything. The Social Web IS the Web.

But specifically: social media, blogs, image and video networks, forums, etc.

starting with: The Fediverse

​

Define "portability"?

That's this session! (Stay tuned)

​

The Dream

Identity and Data Portability on the Social Web

​

Be able to:

1. Move your identifier (e.g. from one domain to another), data stays the same�
2. Move your data (to another host), identifier stays the same

We've Done It Before!

Example One: Phone Numbers

​

Don't like your mobile provider?

You can move to another provider, your identifier stays the same.

​

Don't like your identifier (phone #)?

Get another one (from the same provider).

We've Done It Before!

Example two: Email (and DNS/web domain names)

​

Domains:

• Can move data hosting providers (or domain registrars)
• Can move identifier (domain name), keep data same

​

Emails:

• If you have your own domain, you can move email hosting providers, identifier stays the same
• Email export format (inbox format) is standardized (sort of)
• I can export my inbox from Gmail, go elsewhere. (with limitations)

What About the Social Web?

Current State of the Art - Traditional Social Media (Twitter, Facebook)

1. Identifier?
1. can change within a provider (change username)
2. can't move it to another social network�
2. Your Data?
• can export SOME of the data (thanks GDPR!)
• nowhere to take it (nowhere to import. yet.)

archive of your account, activity (messages), interests, and Ads (thanks!)

Notice what's missing?

What About Social Graph Portability?

On traditional social media?

FORGET IT

• (web scrapers, at best)

​

Your Social Graph IS the moat (primary asset)

What About the Decentralized Social Web?

What about the Fediverse (Mastodon, other Activity-Pub based services)?

​

BETTER.

​

​

Data to Export

In general, by "portability" we mean we want to move data and identifiers:

1. Account profile
2. Contents
1. Posts, pages, comments
3. Social Interactions
• Likes, Upvotes, etc
4. Social Graphs
• Follows, Followers, Friends
5. Media and Attachments
6. Moderation Data
• Blocks, Mutes, …

What about Import?

currently, limited…

What About Move Account?

Export and Import are not the only way to data portability…

IF your old server is up (and cooperating), can we do automated transfers?

• Move identifiers? (No - identifiers based on domain)�
• Move social graph? (Followers/follows) - YES, Partially�
• Move activities and contents? (Not really. Challenges)

The Dream

What do we want?

​

AUTOMATED transfer of data and identity.

​

Why automated?

Well, manual transfer is always possible (re-type everything from memory)

Portability Types

1. Data Export
1. Data Import�
2. "Live" Migration -- cooperating Source server
• Authorization between Source and Destination server (such as OAuth2) (Lisa Dusseault, Aaron Parecki and others)
1. if OAuth2, what do the scopes look like?
2. What about client id / pre-registration?
• What to do with the "old" (Source) account? Delete it? Leave it up? Redirect?
• Can a person switch back after trying out the destination server?
• Follow https://github.com/swicg/activitypub-data-portability repo!�
3. Migration from "Dead" Server -- Source server missing/not cooperating

Portability Challenges - Live Transfer

(solutions / specs / implementations in progress) See LOLA Portability spec.

Standardize:

1. Auth: Authentication and Authorization between transferring servers
2. Protocol: Account transfer API endpoints

But also:

• Identity? (two-way links -- "previously known as")
• What about social graph? Follows: easy. Followers: hard.
• What happens to old posts?
• What about likes/reactions?

​

Portability Challenges - "Dead Server" Export/Import

What if the old server no longer exists? (Or is not cooperating?)

​

Currently, authorship/provenance is controlled by the server.

​

Is it possible to do automated migration (import) from dead server backup?

While RETAINING as much as possible -- old identity, contents, SOCIAL GRAPHS?

​

Portability Challenges

1. Domain-based identity
1. AP actor URL
2. Webfinger url
3. DIDs and other cryptographic identifiers�
2. Domain-based object IDs
• Moving objects (to a different domain) vs using "portable" object IDs / CIDs
• Tracking object history (edits, moves)
• "Move" activity announcements. Standardized "prior IDs" mechanism�
3. Standardized Export Formats
• Actor Profile
• Social Graphs
• Contents
• Metadata�
4. Moderation of migrated content

Calls to Action

Join us at the W3C Social Web Community Group's Data Portability Task Force.�

1. Help us work on Live Server transfer spec (LOLA)�
2. Help us standardize Account Export
1. Account Export Format FEP
2. Export Service Endpoint FEP
3. Help advance the Portability Roadmap

​

Follow: https://w3c.social/@socialcg | Mailing List | Github Repo issues

Bonus: The Roadmap

1. Finish the Live Migration (LOLA) Report�
2. Show C2S (Client-to-Server) ActivityPub API some love�
3. Un-bundle the current "instance" model
1. Provide alternatives to domain-based identity (more than username + password)
2. Separate out identity from content storage from inbox/outbox routing
3. Think "Headless" storage servers and Inbox/Outbox AP providers
4. SIGN EVERYTHING :)�

See in-progress FEP-7952 PR.

Bonus: Hollo Implementation

​

Export from one account, import in another (cross accounts, cross domains)

​

Demo video: https://drive.google.com/file/d/1aPJe1J2--huVvO4Z6F6_MdhqAZOLkc0X/view

​

Bonus: Cross-Protocol?

Live Migration:

stay tuned for Bounce: https://blog.anew.social/bounce-a-cross-protocol-migration-tool/

​

Cross-Protocol export? coming soon.