Account Migration: Expectations / Requirements

Continuing the discussion from Account Migration:

I have some opinions on designing a feature. I always like to make clear what the objectives are. In particular for something like Account Migration, where there are a lot of stakeholders. It would be very helpful for somebody to maintain a list of the requirements per Stakeholder. I’m just posting a list of stakeholders below.

Identified Stakeholders

For simplicity, we will assume that Steve is migrating from the instance Abel administered by Alice to the server Banach administered by Bob. So let’s make a list:

  1. Steve, wants to move from Abel to Banach
  2. Alice, wants Steve to leave her server and be rid of Steve’s stuff
  3. Bob, wants to welcome Steve and take in Steve’s stuff he finds acceptable. Bob also wants to be sure that Steve’s stuff is actually made by Steve and not some imposter
  4. Tina, Ulf, and Victoria — Steve’s friends — want the migration of Steve from Abel to Banach to be as seamless as possible
  5. Kyle and Linda — random users — that sometimes come across Steve’s stuff want their experience to be without annoying “not found” responses. In particular, they want links to replies, quotes, etc … to still work
  6. Helge, technological visionary, wants all this to work without a centralized resource. The best case is Abel doesn’t need to know about Steve after the migration.

Did I miss anybody? Could somebody actually get the feedback from the actual people what they desire?

I’m pretty sure I could create a longer list of requirements for Account Migration. However, I think actually collecting people’s opinions would be more valuable.

Once we have the requirements, it would probably be useful that somebody writes them up as a list and it gets published as a FEP. This would allow one to pinpoint much more easily why certain ideas on how to do stuff are bad.


I would probably expand “take in Steve’s stuff he finds acceptable” to include members of Bob’s servers. Local communities are often vocally invested in the policies and standards of their server, and I foresee a lot of friction arising around migrating post archives that were acceptable in one server, into another server where some non-trivial portion of the posts run afoul of local standards.

In fact, I would list the receiving community as a stakeholder distinct from the owner/admin of the receiving server—not least of all because admins and the administered aren’t always in accord on these things.

Along similar lines, I wonder if maybe the departing community might not also have some stake that we’re not fully anticipating here. One question that occurs to me is: How are posts that were initially addressed to only the local community handled? The Hometown and Glitch forks of Mastodon, for example, have options to restrict federation on posts so that they only appear locally. Local-only posts are sometimes used to discuss internal community business. What happens when Steve tries to migrate those posts to Bob’s server? Technically, they will become local to the receiving server. Does that make internal communication from Alice’s server visible to members of Bob’s server?

Along similar lines, what about DMs. It’s fairly well known that DMs on most AP implementations are insecure, and that a sufficiently motivated server admin could read those ostensibly private messages. Third-party trust is an inalienable factor in those communications. So maybe Ingrid trusted Alice when she DM’d Steve, but she definitely does not trust Bob, who now stands to gain access to those DMs.


@helge - Fabulous list, thanks for starting this!
I totally agree, we should put together a list of Use Cases (which starts with stakeholder list)!

Would it make sense to divide the usecases (and actors) into - 1) Cooperative Source Servers, and 2) Uncooperative Source Servers (which I think is what you’re covering above)?

1 Like

I think you get at this a little bit, but to call it out explicity:

  1. Banach’s moderators (not just Bob, the admin) want Steve’s content to be available to review, and also not burdensome to review
  2. Abel’s operators (again, not just Alice) want offboarding Steve’s content and maintaining future interoperability to not be particularly taxing
  3. Banachs’s operators want similar things regarding the onboarding of Steve’s content.

And I think that review question raises some additional privacy concerns, similar to the issue with non-public content @lrhodes raised. Like, should Abel include reports they’ve received about Steve? Should they include reports Steve has sent?


Back to the technical side for a moment: Might Bob also want to know what sort of demands importing Steve’s archive will put on his server? If Steve is importing a Terabyte of video and image posts, Steve might need to know that before accepting the move.

1 Like

I might be able to write this up. I started spitballing possible FEPs in the other thread but I like this idea of hammering out the actor model first. i was actually just reading this report by Yoel Roth today, which feels like corroboration of the importance of this approach:

(Src ; the link leads here to François’ 2019 paper)


Thank you. :+1:

Reading the responses, I’ve noted something to clarify: Do people expect to be able to migrate non-public content? If yes, are they fine with only getting their side of the conversation?

I can only speak for myself but I would think one-sided conversations might be a good starting point, with both-sided conversations (and all the complex authZ it entails) maybe deferred for a later extension spec or only available when both migrated-from and migrated-to have also implemented additional FEPs?

If each activity and message were a finite object with a static URL (and/or a CID or other static URI), authZ to access it could be separate from the export of the pointer to it…

I’m not sure if I would expect it. I think I could be fine with or without it. But I would certainly want to know which it is.

1 Like

Something that just occurred to me: there’s a decent chance when moving to a new server, the new server may already have copies of some of the content from the old server. What should be done with that?

Probably keep it, maybe attach it to the new profile in addition to the old profile.

Can we stick to the format of stating things as expectations, i.e.

  1. b. Bob — administrating the server Steve moves to — wants to avoid storing duplicate objects.

My reasoning here is that all these questions have various technical solutions, e.g. FEP-fffd: Proxy Objects, but what should be implemented depends on how migration is implemented.

My expectation is that a good implementation should clear 2/3 of the requirements by virtue of being a “good implementation”. Not that I currently know what this good implementation is.


I just saw on the Fediverse:

wait did I just lose access to all my inbound DMs and follower-restricted replies from the old instance?
my archive contains my outbound posts, but nothing inbound loooolololol

[battening down to be yelled at for assuming that the software understood human ways of using comms channels]
eta: I always initially blame myself for my software problems, don’t worry! but also I read so many things about migration and “you will never see your DMs again” didn’t make it into my brain at all. it’s all low-stakes here bc I barely use DMs but I value some of the inbound stuff a lot more highly than my own dumb posts.

So I guess the answer is: Yes people expect to be able to migrate non public content. And they are not fine with only getting their side of the conversation.

I guess the way to narrow down the expectation of people would look up what they write after a migration and collect their complaints (or compliments). I’m just going to do this, when I notice it. So somebody actually making the effort to track this down in a systematic way would be appreciated.


@by_caballero Did you get a chance to write something up on these expectations / requirements?