(2023-05-01) Portable Identity For Activitypub

Portable Identity for ActivityPub. I want to focus on: portable digital identity. The idea that I should be able to take all of my data, everything that my identity consists of, and move wholesale to a new instance/server/PDS/whatever you call it. Bluesky permits this. Mastodon and most (all?) other ActivityPub implementations do not. But that doesn’t have to be the case, nothing about ActivityPub—architecturally speaking—is incompatible with this vision.

The ID of post tells you where it is. However it doesn’t just identify where the document can be found; it also identifies where it’s hosted. This property is true of all object identifiers in Mastodon (and just about every other serivce that implements ActivityPub).

My posts don’t belong to the service I’m using to host them. They belong to me. The identity of the posts I published should be tied to me and not to the service I’m using to host them. That is, the IDs need to be resolvable through something (hint: a domain) that I control before ultimately reaching my host.

To make this vision of portable identities to work, there needs to be an additional layer that performs the mapping of identities to hosts.

For people who own domains, this is easy: they just point the DNS records at their host and tell their host that their identity should be served from their domain. Migrating your identity to another host is then a matter of updating DNS records.

The hard part however, is the social one: we collectively need to agree that the identity resolution layer is infrastructure and not somewhere moderation actions should take place. To use the web analogy again: people publishing objectionable content get kicked off web hosts, but it’s far rarer that their domain name is taken away.

The key advantage of this approach is that resolving a portable identity or object ID into a concrete ActivityPub object is no different than it is now. You just make an HTTP request, and get back an AP object.

So under this vision, what does the complete migration process actually look like?
You export an archive of your account from your current instance. You import that archive into your new account. You point your identity at the new server (either by changing your DNS records, or by updating your information in the resolver’s directory described before).

If you look at Mastodon issue #12432 “Support Post Migration”, you will find an incredibly long thread spanning three and a half years of discussion. The discussion primarily comes down to the fact that Mastodon’s architectural decisions are not conducive to this approach.

there is no way to know who has a copy of a post that’s moved. After an account migration, there will be stale links

I am not familiar enough with the Mastodon codebase to say whether moving to the vision I’ve outlined is feasible. If it’s not, I think Mastodon should continue to pursue alternate methods

There is, to the best of my knowledge, only one single ActivityPub project that supports multiple domains: Takahē. Multiple accounts across different domains being backed by the same host doesn’t get us all the way to portable identity. But the architectural decisions required to support it go a long way towards that vision

Update: There is an AP implementation, Bovine, which stores and identifies AP objects by their AP identifier, which goes a long way towards making this implementation of portable identity possible.

How do you keep my old instance from impersonating me?

Why not DIDs? ATProto uses DIDs, rather than URIs, for identifiers.