A Portability Roadmap: One Approach to Account- and Data-Portability for ActivityPub

Introduction

One large focus of the social web coöp's work in this last year has been testing, which I described in the previous long blogpost. The other main focus area was "Account" (i.e. Actor) and "Data" (i.e. Content) Portability, which coincided fortuitously with the formation of the Portability Task Force spinning up in the W3C Social Web Incubator Community Group after we had scoped out and planned the project. By consensus, that Task Force chose as its first and main focus an API-based, OAuth-authorized migration flow described in the LOLA Report for Live-Online Account Portability, the current Editor's draft of which can be found here. "Backups" or "Data takeout", as well as portability from a "dead" server or one hostile/non-federating to the target server was out of scope, as were a number of other user-stories we described in the Migration User Stories document we wrote and published earlier.

Of course, LOLA is urgently needed and it is indisputably a step towards better user experience and viability of the protocol to "pave the cow path" used by most of today's users to migrate between server, i.e. the Mastodon-API-based server-to-server "Move Actor" flow (retro-specified by community contributor and ActivityPub implementer @silverpill). As Erin Kissane's widely-read blog post detailed, a "minimum viable" migration capability that only allows moving between Servers implementing not only the Mastodon API but also its data models and internal data structures, severely disappoints end-users bringing contemporary UX expectations! But there are painkillers (triaging the most urgent capability deficits of today's ActivityPub software) and then there are vitamins (upgrading the protocol as a whole to allow better software to be written).

In this spirit, the coöp reviewed closely and contributed to the writing of the LOLA specification with an eye to the future of the protocol, while also discussing with the task force an orthogonal export-import solution that would work across all of today's and more of tomorrow's architectures and implementation styles. This latter was accepted as a work item of the Portability Task Force, and we will be pursuing its review and eventual acceptance as a Community Group Report if all goes well in the coming months. But this work item is best understood as a small part of a bigger story, which was our actual focus over the last year, and the culmination of other work, which I'll outline briefly.

The Big Picture

Over the course of our year of community work and research, we discussed internally and publicly what the "big picture" of portability was for ActivityPub as a protocol rather than as a network or a platform. As I outlined in our previous long-form report, this paradigm shift to get developers and users thinking of "the protocol, not the platform" (to borrow a phrase from Mike Masnick) is turning out to be perhaps the biggest challenge in the ActivityPub developer community! Separating out platforms and their software from the protocol underneath them helped us to imagine a future for the protocol that is more agentic and portability-guaranteeing software. Working backwards from that vision of the best-possible protocol allowed us to map out how today's platforms and their software can be evolved to get there.

Bengo wrote a detailed blog post on his own site, which outlines a bit his own personal Big Picture and, more importantly, his proposed "2025 Vision" for what a fully-portable and flexible protocol could look like a year from now with a little courage and innovation. Rooted in his own long and personal history with the protocol stretching before its specification, the article reframes many of the gaps between status quo and a fully-portable, fully-agentic interpretation of the protocol as different interpretations of the protocol as-written.

I won't summarize it further because I think the blog post speaks for itself, but suffice it to say that the vision is shared by the cooperative, and deeply informs our contract deliverables and community contributions detailed below.

Waging Protocol Evolution on Many Fronts

Another document we published was FEP-7952, a "Roadmap for Actor and Object Portability", which attempts to sketch out at a high level, for the designers and developers of today's implementations, one possible path towards solving the daunting challenges outlined in Bengo's essay. Without going into as much detail on protocol interpretation or philosophy, it was conceived simply as a neutral explanation of how various FEPs can fit together and be seen as stepping stones towards greater portability and cohesion between software, all the more manageable if tackled in a certain order ("one FEP at a time", as it were, borrowing from the Improvement Proposal culture of many decentralized developer ecosystems).

This document spells out four "epics" that would move all implementations towards a more agentic and user-portable paradigm:

1. "Unbundle" the services and concerns of a typical instance
   • The most important (and only non-optional) feature proposed here was publishing public keys per-user and signing each object at time of publication, according to two FEPs that predate our work and have already been adopted into Fedify, a promising new open-source Typescript library that we think is nudging the developer community in many productive directions.
2. Implement Portable (migration-stable) Object IDs
   • Here, multiple possibilities are mentioned for how servers hosting content for actors could make their own object IDs long-lived or server-independent, but the important part is not hard-coding server-dependent trust models as the only possible ones into the consumption of other servers' content!
3. Create account export/import features that assume Actor-Relative URLs and segmented services
   • This is explained more below
4. Enable verifiable Actor URL migration
   • This was outlined in User Story #5 in FEP-73cd

Strictly speaking, 2, 3 and 4 are orthogonal and could be tackled in any order or worked on in parallel, and really, getting community support for any of these gets us to a better place, even without the others.

The export format and endpoint

After all of our research and our engagement with the LOLA specification, we had a clear shopping list for what kinds of data should be included in an "account export" of the kind that have been pioneered over the last few years by the Data Transfer Initiative. (It's worth mentioning that the editor of LOLA is DTI's CTO, Lisa Dusseault, and her experiences on enabling portability for commercial platforms, informed by and informing policy and regulation, were a substantial influence and we're lucky to have gotten her input on priorities and feasibilities!) There were, of course, some sticky data types left strategically out-of-scope (like direct messages and key material), but in the coming months and years these thorny issues might become less thorny as messaging and cryptography separately advance as protocol extensions in their own right.

Like the LOLA specification, the export format and the export API design are both likely to see substantial change after implementer feedback and hardening in the Data Portability task force, but we're confident our draft specifications and our prototype in the Hollo framework for Fedify will help accelerate this adoption.

Next steps

The decentralized social media space moves fairly quickly, and user expectations (around user experience, portability, recoverability or verifiability of content published on a since-defunct server) are changing fast. We hope the developer community around our beloved protocol can adapt quickly, but it will likely change hands and foci many times as these seeds we've planted grow (hopefully) into standard features and capabilities. Community work and design in the open both take time, and our cooperative is planning next steps (hopefully including grants in the short term that would enable us to be as involved in next steps as we've been so far). That said, it hopefully doesn't matter if we (as a cooperative or as individuals) are involved or not, because our north star in all this work has been self-documenting as we go and making our work maximally "forkable" by unknown future implementers and advancers of the protocol.