Basic idea to move users between pods on D*

I'd actually like to see an export of all data we wish to retain during the move, the reason is that it would make the move feature a backup feature with no basically additional effort, allowing a move even if the original pod went down. With that idea a few more semantics can change, see my old writeup: https://github.com/MrZYX/old_diaspora_wiki/blob/master/Seed-migration-proposal.md

Totally agree, I'm only focusing on the move right now, I wan't to shut down one of my pods as cleanly as possible and move the 1 user on it to my newer pod.

I'm trying to keep it simple first, move the user, let them rebuild their stuff. If someone feels like focusing on export/import (regardless of pod) that would take care of both too.

I've looked a the existing export, no ones maintaining it. People are adding relations to the user/person models and none of them are getting put in the export.

To me the export is a solved problem, it's just a dump and reload of data, someone just needs to take ownership of it. People have manually moved before, I (yes i now its not for everyone) can sit there and poke my data back into the DB, not a big deal. The big issue was how to move the actual user/person relationship from one to another and notify everyone it happened, I believe what I proposed solves this.

Sure and I wouldn't mind a first version not migrating the data, but I think we should decide whether we want to support migration when the original pod is down and you just have such a download laying around. We can totally strip the data stuff from my old proposal and have that, if we don't want to support that use case yours is fine as it is.

Another issue both our proposals don't accommodate:

It's quite frequent that a pod receives a comment or a post (through a reshare) from a third pod and fetches the authors profile there. The third pod doesn't keep track of that and there's no contact from or to a user on that third pod. So the home pod of the fetched user doesn't know that he should send a move notice to the third pod. If then after a move someone from that pod want to contact that user, that'll fail.

Perfect, that last thing is the kind of issue I was looking to locate. I knew it could happen, but I couldn't work out exactly how. Will work on something to try solve that.

Totally love this idea - I think having this solved would bring a lot of confidence in to the project, since many people seem to feel it was one of the original promises in the kickstarter (umm it was I guess :)).

+1 for implementing this if you are up for working on it @ruxton :) No solution needs to be perfect at the beginning - that is impossible, the best way is to make something and iterate over it.

As for the export, it would be nice that these two would complement each other. After all, both ideas can use the same contents for the profile ("(and maybe serialized profile)" -part). Please make it JSON, not XML? :)

One idea I was going to write about was some kind of automatic backup of user profile/contacts/posts (without picture uploads) to*another pod*. This pod could be chosen randomly from participating pods (like "allow_backups" setting) and each user would automatically have their data backed up on a random pod. The data would be encrypted so that it could only be opened with their private key, which would given to download for the user on registration (with instructions to store it safely - loss of key=loss of backups).

In the event of catastrophe at the users pod, the user has the option of either downloading data or opening an account using the backup profile, on the other pod - which is when they would need to private key.

In this way user data would be backed up somewhere off-site, making it less likely for user to lose everything if the pod goes down. Also the pod which has the backups would not be able to read the backed up data, until user opens it with their key. The only issue I would see is that the backups would have to of course be incremental - which could be an issue as the data would need to be sent over encrypted.. Also the whole thing shouldn't cause too much strain on the pods of course.. DB space is hardly an issue for just post/profile data with no relations - and I'm 100% sure lots of pods would gladly participate.

But really, the only way imho to solve the problem of dying pods is to make it somehow not require user action. Requiring one to manually download data "as a precaution" is not really a working model. Maybe when we have the API there could be clients to automate it of course, but then that would be a big strain on servers ;)

But sorry for rambling in (mostly) unrelated things - would totally love to have the possibility for users to migrate pods!

Whoever solved this would be my absolute hero for ever!

Jason's right: we agreed to use JSON for the export: proposal here.

@jasonrobinson In principle, your idea is quite nice, even with all the technical details to be figured out. The only real conceptual problem I see is that the "automatic backup to a random pod" defeats the whole "choose the pod you trust" idea. ;)

The only real conceptual problem I see is that the “automatic backup to a random pod” defeats the whole “choose the pod you trust” idea. ;)

Well of course there could be a "let me choose" instead of being random :)

My point is - default experience IMHO should be as little need to decide as possible. Because most users don't like clicking through a gazillion things to just get to the application.