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:
Steve, wants to move from Abel to Banach
Alice, wants Steve to leave her server and be rid of Steve’s stuff
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
Tina, Ulf, and Victoria — Steve’s friends — want the migration of Steve from Abel to Banach to be as seamless as possible
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
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)?
I think you get at this a little bit, but to call it out explicity:
Banach’s moderators (not just Bob, the admin) want Steve’s content to be available to review, and also not burdensome to review
Abel’s operators (again, not just Alice) want offboarding Steve’s content and maintaining future interoperability to not be particularly taxing
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.
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:
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…
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?
Can we stick to the format of stating things as expectations, i.e.
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.
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.
I tried to incorporate all the insights of this thread into a re-write of your initial use-cases, to decompose various goals and use-cases. If anyone notices something I missed, please point it out!
I couldn’t agree more. Before composing crisp use-cases that each require one or more functional FEPs, let’s try to hone further your migration flows a bit more. I am assuming and hoping that only a small subset of the following gets marked as “urgent”, but still enjoy an exhaustive thought exercise as much as any other masochist.
Assuming users:
Alice
Bob
Charlie
Daniel
and Servers:
Alpha (the OG)
Beta (Rancid - defederated by rest of the list)
Gamma (New Kid on the Block)
Delta (Dead)
Epsilon (Effectively a blog)
Zeta (Not even invented yet)
Alice wants to move from Alpha to Gamma, both of which are online and federated to one another. Four possible variants (not mutually exclusive):
A. Alice would like her account on Alpha terminated with some kind of human-readable redirect, i.e., links to old Alice@Alpha content display a warning that “Alice doesn’t live here anymore”
B. Alice would like Alpha to dynamically redirect any links to Alice@Alpha or to any specific content she posted/generated there to a reasonable default “homepage” for Alice@Gamma
C. Alice would like Alpha to dynamically redirect any links to Alice@Alpha content to the migrated contents @Gamma (i.e. 301 HTTP codes and nginx-style URL rewrites)
D. Alice would like her account on Alpha to remain active and accept new posts, but would like her followers to know about the new account as well.
Bob is asked to leave Alpha by its moderation team, who have disabled new posts on that account but are allowing Bob to log in to facilitate a one-way, permanent migration to a new server of Bob’s choosing as a courtesy.
Bob finds a new home on the server Beta, which is specifically de-federated by Alpha for incompatible moderation policies. Bob would like to announce to his followers his new account, without Alpha and Beta having to communicate with one another.
Charlie would like to move to Gamma from Delta, because the latter was recently and unexpectedly taken offline by government intervention. Before going dark, Gamma had already authorized a custom client for Charlie, which he used to sign each posts with a self-managed private key, and Charlie had backed up his posts and media a few months prior.
Server Delta, when Charlie uploads his back-up of content from Gamma (RIP), would like to check Gamma’s moderation records before importing the archive. While Gamma is no longer online, Charlie does find a recent backup of Gamma’s moderation records that was more recent than his backup.
Server Epsilon, which Daniel wants to migrate to from Delta, has no moderation policy because Daniel is its only user and he has full admin rights over it. Daniel logs into Epsilon and loads a recent backup without having to worry about Delta’s policies at all.
Delta did not support all the same features and Activity types that Gamma did at time of Charlie’s import.
A. Delta’s import wizard warned Charlie to keep his backup and try again later. Years later, he does, and additional content is imported now that Delta supports a bigger subset of Gamma’s Activity types.
B. Delta stored all un-imported data in a separate archive for Charlie. Years later, when Charlie goes to export his Delta content, both the un-imported Archive and the imported content alike get included in his backup, and it all gets imported to Zeta.
Notes on how to proceed & to-do list:
I believe that 1A and 1B are roughly supported by Mastodon and a few others, with lots of nuances and corner-cases and subtle differences of semantics and expectations. I agree that documenting status quo will greatly clarify the upgrade path whatever mechanisms people design! I think silverpill’s FEP already retrospecifies this pretty well (with all the right extension points to make it compatible with the other user stories), and i think it’s a small enough lift that other implementations could rally around it and implement that while other user stories are debated, designed, and FEPd
I left aside the nuance of 2-sided conversations and non-public content for now
Obviously a lot of these are low priority/backlog user-stories. But I felt it might help de-prioritize them to describe them as user stories, so feel free to bikeshed or workshop them even though they won’t get implemented for years
Context: after a little more group-thinking on functionality targets and requirements, I would like to start a new thread with a WIKI in its first post collecting user stories that map to FEPs.
