Basic idea to move users between pods on D*

Maybe uploading to FTP/OwnCloud/DrobBox/something would be an option for automatic backup? Or isn't it better to put effort into implementing an API instead of automatic backup? Server strain could be reduced by allowing a backup of selected timespan through API.

Stolen from a post I made online:

From what I can see, account migration would have to have a few objectives:

Let's assume we want to migrate a user's data from account x on pod A to account y on pod B

• The user informs pod A that he's migrating to y@B. The user initiates the migration from his account y@B.
• Pod B requests Pod A send copies of the x@A data to y@B. This includes posts, images, comments, messages, etc. and account connections (e.g., start sharing with the same accounts on y@B as x@A was). Pod A would reject any migration other than to y@B, and uses https certificate validation to ensure it is sending data to the correct pod. Pod B could send a nonce/token to Pod A in its initial message, which pod A sends back with the x@A data for additional security.
• Pod A could send out a message to other pods indicating the y@B is the new home for x@A. Pods hosting accounts sharing with x@A could verify the move with pod A and automatically start sharing corresponding accounts with y@B while unsharing x@A. Another alternative would be to send a message to any user sharing with x@A about the move.
• After the move is complete, manage interactions with x@A. This could be as simple as a disallowing comments on existing posts/messages with an appropriate message, or as robust as redirecting posts/image requests/etc. to the new pod via 302. The user x@A should not be allowed to create new posts/messages/comments anymore. In fact, deleting the pod A account should be the only modification x@A is allowed to do, or perhaps initiating another migration.

I've outlined a fairly complex state machine and will probably require more transitions than what I've described (e.g., aborting the migration). And probably a fair amount of code.

I like what everyone has put here so far! My thoughts on how the process could work:

1. User logs into their home pod
   
2. In user settings, user can authenticate to an account on a remote pod using OpenID Connect and a Diaspora Migration API. You could almost think of it as the remote Diaspora pod being treated as an authenticated app.
   
3. Posts, images, and contacts get sent securely to remote pod using API.
   
4. Existing posts on original pod somehow are turned into references/redirects of some sort that point to the duplicates on the new pod. We may need to implement a proper way to revise posts via the API in order to successfully do this.
   
5. After a determined amount of time, original posts are deleted once the new references get federated out to everybody.

I recall it was ONE of THE FEW BASIC features promoted by Diaspora !

It may be basic, meaning fundamental to Diaspora's concept, but it is in no way basic, meaning simple to create or implement. On the contrary, it's extremely complex to do properly. That's why it's taken so long!

@ruxton confirmed he will not be working on this (on Twitter) - so anyone who wants to, feel free to participate in tuning the idea and/or creating an actual spec for the migration.

@jonnehass also has an old draft - https://github.com/jhass/old_diaspora_wiki/blob/master/Seed-migration-proposal.md

We really need to lock down a spec before any work can be done..

One (IMHO) good place to write up a spec is here: https://wiki.diasporafoundation.org/Category:Proposals

It would be great to get this implemented as I think it would reinforce the idea that D is decentralised in potential users minds, and give them more confidence in it. Also it would be a really cool feature.

I'm not sure that allowing the user to back up to another pod is a good idea, mainly from a perception point of view. I think any backups should be dealt with from the podmin end, however I still think allowing a user to download their data is a good thing.

I’m not sure that allowing the user to back up to another pod is a good idea

The proposal is about migrating data from one pod to another, not backing up data from pod 1 to pod 2 while remaining active on pod 1.

@goob I was referring to an idea Jason mentioned in his post.