Account migration considerations

From diaspora* project wiki
Revision as of 13:49, 19 October 2018 by Senya (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page is for outlining design decisions about how account migration feature works or should work, especially for its complicated parts.

Diaspora software must reject account migration request if it knows that the "old person" of the request has already migrated elsewhere.

Account merging

Account migration feature should support account merging as soon as possible. Account merging means that the target ("new") user of the account migration is not necessarily empty and may contains some data.

Was discussed at: https://github.com/diaspora/diaspora/pull/7660#discussion_r181918062

Importing archives of unknown users

If the pod which is requested to import a user archive doesn't know the archive owner and fails to fetch it then it still should import the archive and send the AccountMigration federation message to other pods, but it must not save the AccountMigration DB entry.

Reestablishing contacts

When a remote pod receives an AccountMigration message it should send the Contact object back for each updated contact so that the new user's pod can reliably update the mutual contacts.

The new user's pod (the one that imports archive) should also send the Contact message to each imported contact after the account migration procedure is finished. While it is not necessary for the mutual contacts, it is required in case when there is no contact information at the remote pod (e.g. we're importing archive of a deleted user or relationships have changed since the archive creation or user manually altered the archive contents).