Account portability in the social web

Social networks, and websites with a social element, are starting to migrate from being walled gardens towards interoperation and open standards. This is comparable to the adoption of email standards by companies such as AOL in the 1990's.

In an interoperable world, users want to be able to move between providers with minimal friction to avoid “lock-in”. Switching email providers easily is taken for granted. Switching social networks should be just as easy.

In the social web, also known as the Fediverse, the two main pieces of data that need to be moved are the account, including its social graph of followers and followed accounts, and the content associated with the account, such as posts, articles, photographs, music, video, and the like.

Account portability elsewhere

Account portability is a common requirement in other settings, but is never implemented perfectly.

When you change address, you might tell most people who send you post about your new address. Then, to catch any you missed, you might set up a postal redirection from the old address to the new address, for a given period of time. After that, any post sent to the old address is unlikely to get to you.

When you change mobile phone networks, you are given a new phone number, but you can transfer your existing phone number to the new network. After the transfer, anyone who phones your existing number can get through to you and this is a permanent state of affairs. You'll lose any voicemails associated with the old network.

If you change email providers, you'd probably tell your contacts your new email address. Then, to catch anyone you missed, you could set up forwarding from your old email address to the new address. If you eventually delete your account with the old email provider, the forwarding will stop and people will no longer be able to contact you through your old email address. You'll also need to download any emails stored by the old provider that you want to keep.

Or, if you have set up an email address at your own domain name and associated that with an email provider, you change email providers by associating your email address with the new email provider. People can email you throughout the process without being aware that the change has happened.

Account portability in the social web

ActivityPub is the protocol that underpins the Fediverse (Mastodon, Pixelfed, PeerTube, etc.). It does not provide direct support for account portability. However, Mastodon builds account portability on top of ActivityPub, with some limitations described by Erin Kissane in Notes From a Mastodon Migration. It will be fascinating to see to what extent, if at all, interoperation with the Fediverse by Meta's Threads will include account portability.

The AT Protocol underpins Bluesky and claims to support account portability such that a user can move off an instance without that instance's cooperation, for example if the instance is offline or the user has been banned. This feature was cited as one of the main reasons Bluesky did not adopt ActivityPub. Whether the feature works well is hard to tell since AT Protocol only seems to be implemented in one place (bsky.social), although Bluesky does support domain names as handles.

Work in progress

Efforts to build account portability on top of ActivityPub fall into three categories: abstracting identity, improving account migration, and migrating content.

Abstracting identity

The approach here is to create an identity independent of any server and then associate an account with the identity. Account portability can then be implemented by changing the account associated with the identity.

There are a couple of general ways of abstracting identity.

  1. Own domain name identity

    The first is for users to identify themselves using their own domain names, sometimes called Bring Your Own IDentity (BYOID).

    It may not be practical or affordable for users to own their own domain names. However, subdomains can have their own DNS records, so it would be a straightforward business opportunity to rent out thousands of subdomains cheaply and provide a web UI. But this would probably need to be done by a trusted non-profit or public body with suitable backing for it to be sustainable.

    One way to use domain names as identities would be to mirror email account portability. The association between an identity and an account is analogous to how an email addresses can be associated with an email provider: by using a MX record in the DNS for the domain name of the email address.

    The primary actor’s domain name would have a SRV record defined in the DNS. The SRV record would point at the server currently associated with the primary actor. To move the actor to another server, the SRV record would be updated. To make this secure, the server would need to be configured with the primary actor analogously to the way an email provider is configured with an email address.

    To illustrate the idea more concretely, I defined the following SRV record for the hostname toot.underlap.org:

    Type: SRV
    Service: _activitypub
    Protocol: TCP
    Points to: fosstodon.org
    Priority: 10
    Weighting: 0
    Port: 80
    TTL: 1 hour
    

    (The service name _activitypub is non-standard and would need to be registered with IANA to avoid collisions.)

    An advantage of this approach is that it builds on existing DNS concepts and tooling and should be relatively straightforward to implement.

    Other ways to use a domain name as an identity include storing links to profile information in DNS TXT records and dereferencing identity URI identifiers using webfinger.

  2. Cryptographic identity

    Another way of abstracting identity is to use cryptographic tools such as OpenPGP (and its derivatives such as Keyoxide) to prove ownership of accounts and authorise migration between accounts with the same owner.

    This provide better privacy than using domain names, but the identities can be less readable. It also can avoid the need for centralised authorities such as those used in DNS.

Improving account migration

There is a Fediverse Enhancement Proposal FEP-7628: Move actor (with associated discussion) for extending ActivityPub to support moving “actors” (similar to accounts) between servers.

Meanwhile @evan@cosocial.ca has been drafting a data portability report and @robin@mastodon.social has even suggested a proposal to implement ActivityPub on top of the AT Protocol.

Migrating content

Various Fediverse servers provide basic facilities for exporting and importing data, although there is no standard export format, so this is most useful for backing up content and migrating content between servers running the same software. Firefish is unusual in that it can import posts exported from Mastodon.

Another approach is to allow data to be stored independently of a particular server. FEP-ef61: Portable Objects identifies data (and other ActivityPub objects) using server-independent IDs instead of HTTP(S) URLs tied to particular servers.

Conclusion

I hope this has been a helpful overview of account portability. In preparing this post, I ran a poll which received some helpful comments, for which I am grateful.

The area is evolving rapidly so if I've missed any important aspects, please let me know or reply here and I'll attempt to include them below.

Updates

The following were kindly pointed out after this post was initially published.

  1. After my understanding of the ActivityPub spec was questioned, I started to wonder if server-independent identities couldn't be ActivityPub actor IDs (if these are necessarily tied to their servers). However, there are other ways of reading the ActivityPub spec which do allow for server-independent identities.

  2. The IETF DANCE working group is working on associating identity with DNS records. Their latest draft spec is An Architecture for DNS-Bound Client and Sender Identities. “DANCE” stands for “DANE Authentication for Network Clients Everywhere”.

    This spec builds on “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” more commonly known as RFC 6698, or “DANE” for short. DANE allows DNS records to specify keys used in a domain's TLS servers.

  3. On the cryptographic identity front, the W3C spec Decentralized Identifiers (DIDs) v1.0 is relevant. A DID is securely associated with a document describing the subject (similar to a user or actor) identified by the DID, but without requiring a single, centralised authority. The process of determining the document from the DID is known as resolution. The W3C are working on a draft resolution spec.

  4. ActivityPods are bringing together ActivityPub and SOLID decentralised data stores (or “pods”). Part of this abstracts identity.

#ActivityPub #ATProtocol #AccountPortability #Fediverse #SoftwareStandards

[ favicon | about | blogroll | contact | now | popular | subscribe | feed icon ]