For several years now, Anna has operated @anna@beta.example.com an account on Mastodon instance Beta, but has decided that she’d be a better fit on instance Gamma. Under the simplest conception of full account portability, she would be able to reserve @anna@gamma.example.net, input that new address in the preferences on her Beta account, confirm her intention to migrate, then sit back while the two instances coordinate the exchange of the ActivityPub Collections associated with her Beta account to her new account on Gamma. After a few minutes, she should be able to log into Gamma and have at her disposal all of her followers and follows, her blocks and mutes, her lists and complete post history from the prior account.
Currently, that is not how things work on most federated services, but it appears to be the ideal many of us are working toward. I assume that the technical hurdles are surmountable, albeit with trade-offs that warrant caution. What I want to concentrate on here are some social difficulties I’ve not seen widely discussed.
Case 1 involves a post set to Public visibility, meaning it would be included in public timelines and that it could, in principle, be viewed by any logged in account, subject to moderation restrictions. To simplify, assume that this post has no recorded interactions—no likes, no boosts, no replies. Nevertheless, Anna wants to take it with her when she migrates to Gamma. This is the least problematic case, and I think most people would say that it’s a fit candidate for migration. Send it along!
Things get murkier from there on. Case 2 is a direct message from Anna to @carl@beta.example.com. Direct messages on Mastodon are unencrypted—as are DMs on most current social media services, but famously so on Mastodon—which means that a sufficiently motivated admin could query the database to see the content of any DM on their server. Trust is thus a factor (even if only implicitly so) and Anna and Carl both felt comfortable having moderately confidential discussions on Beta because they both trusted their admin, Darius, not to pry. But while may trust her new future admin, Carl doesn’t—or, at least, doesn’t know whether he should.
Should Beta transfer Anna’s DM to Gamma? “Full account portability” would seem to suggest that it should. Are her DMs not part of her account? There may be information in the DM (Carl’s email address, for example) that she’d like to retain for later use. But transferring it potentially violates Carl’s expectation that DMs will only be accessible by certain identifiable parties. Maybe Gamma’s administrator bears a private animosity toward Carl. Either way, making unencrypted DMs portable breaks the social agreement implicit in the DM function. You could say that, at least in potentia, it breaks DM functionality altogether.
One solution, of course, is to redesign DMs around robust encryption. Until that happens, though, DMs should probably migrate only with explicit consent from all tagged accounts, or not at all.
Case 3 concerns a string of posts Anna made during the last election about a sensitive political issue. Instance rules on Gamma allow posts on the subject, but only behind a content warning. Beta doesn’t require content warnings, and Anna didn’t use them on that post. Gamma’s admin is unaware of those posts—they were made more than a year ago—and Anna has forgotten them, so unless someone catches them before her migration, they’ll soon be located on Gamma in violation of its rules. This may not seem like a particularly big deal, but Gamma members take the rule seriously, in part because some of them have PTSD related to the issue, and everyone wants those members to feel welcome. Maybe no one will go back and discover Anna’s political posts, but they might, and their presence there circumvents precautions those members may have taken against having the topic federated into their timelines.
I want to emphasize two points here. One is that, without some form of audit capability, full account portability sharply raises the risk of post hoc rules violations. The other is that, to the extent that an ActivityPub instance hosts a community, the members of that community are stakeholders in those rules. Should they have a say in whether someone can migrate rule violations into the instance? Is it even practical to audit the contents of an incoming account? I don’t see an easy technical fix here—at least, not one that avoids making full account portability more trouble than most people would feel it’s worth.
For Case 4, assume that Beta is run using the Hometown fork of Mastodon. Instance members can flag a post so that the server doesn’t pass it to federated instances, so that the post is only visible to accounts on Beta. This lends itself to lots of use cases, but Beta uses it mostly to discuss instance governance. Anna has been reasonably involved in those discussions, which are conducted on the assumption of discretion. It would be easy for people who weren’t involved to misinterpret them or blow certain disagreements out of proportion, which is why Darius would prefer that they weren’t exposed to the members of another instance. To complicate matters, Gamma is a standard Mastodon instance, so the flag marking those posts as local-only would likely get dropped in the transfer, allowing those posts to federate throughout the network.
Should Darius, as Beta’s admin, have an easy way to prevent those posts from migrating? That, of course, would break Anna’s expectation of full account portability. Allowing them to migrate, though, would break everyone else’s expectation of localization. And allowing Darius to assert a partial restriction could be taken as a general argument for giving admins veto power on account portability.
The technical solutions here seem rather straightforward. A site-wide setting could allow admins to withhold local-only posts in the case of account migration, with notifications informing the account-holder of the restriction. Or local-only posts could be converted to DMs–though that might still potentially expose them to other admins, as in Case 2. Either way, the dilemma points, I think, to the broader principle that some activities belong as much to their context as to the accounts participating in them—a principle that might seem rather obvious in the case of explicitly localized posts, but which, to the extent that it asserts limitations over their desire for full account portability, many people would likely reject.
Case 5 is Anna’s fifth reply in a conversation with Frank on instance Delta, a conversation they were able to have because Beta and Delta are federated. Frank, however, has blocked the entire Gamma domain, so the conversation would not have been easily accessible from that instance prior to Anna’s decision to migrate. How should Beta treat the request to transfer that reply to Gamma?
In principle, this may seem unproblematic. Since Beta and Gamma are federated, a standalone post created on Beta would appear on Gamma, even if the author had tagged Frank in the text. And while Anna’s reply to Frank might not have federated to Gamma on its own, @emily@beta.example.com could have boosted it into the timelines of accounts that follow Emily from Gamma. From a safety and privacy point of view, migrating Anna’s reply to Frank looks like a variation on a question that has already been answered.
But then, what happens to the record of their past conversation? Assuming that Frank’s domain block holds, the connection between their responses to one another will effectively be broken. Frank will no longer be able to see Anna’s responses, and Anna will no longer be able to see the context of her replies. Logically, this is a predictable consequence given the federation parameters in this case, but is that the behavior Anna would expect? If full account portability was a means of preserving a record of her social interactions, this effectively undermines that goal. And Frank may one day decide to revisit that exchange only to find that a decision he made before the conversation has effectively blocked half of the conversation months after the fact.
There may be solutions to the technical problem of a broken public reply chain (e.g. fetching the thread from an unauthenticated view), but it’s impossible to anticipate whether they’re desirable in most cases since breaking the reply chain may or may not be the desired result: Perhaps Anna is moving to Gamma in order to get away from Frank, or maybe Frank really wants to be insulated from anyone who would associate themselves with Gamma.
At the very least, account nomads need to be notified in advance that migrating a post archive could break their prior interactions with other accounts. Full account portability is a simple concept masking a complex range of potential results; it’s important to set expectations accordingly.
More generally, Case 5 serves as an illustration of the principle that social belonging may be multivalent. In technical terms, the entity that “owns” Anna’s reply may be subject to change, but can be described in fairly unambiguous terms using the language of the ActivityPub protocol. Socially, though, the context it relies on for its meaning consists not just of Anna, but also of Frank, and not just of those two people but also, as the dilemma indicates, of the relationship between the instances that host their accounts. Removing it from one or more of those contexts threatens to break its meaning. Will Anna still want that decontextualized post once she has made the move to Gamma? Is full account portability as valuable to her if the result is an account dotted with orphaned replies?
To some extent, the dilemmas in each of these case examples arise because our social media behavior is often calibrated for a narrow context, even if we generally prefer to see ourselves as radically independent individuals standing apart from the network as a whole. Most conceptions of full account portability are grounded in the latter point of view. But that’s not how the fediverse is structured, nor is it how most of us navigate it. The design of account portability should take into account the social principles pointed to here. Otherwise, we’re likely to undermine much of what we value about the spaces we’ve built here.