But, as discussed before, an important step in the import process should be, once the user is happy that the import has taken place correctly, the new pod communicating with the old pod and providing it with a key generated by the old pod during the export process, which then prompts the old pod to delete the old account. This will mean it is a proper migration (leaving the old pod and moving to the new pod) rather than simply opening a duplicate account.
The new pod will also need to communicate with all pods with which the account is connected to tell those pods where the account is now located, so that contacts will not lost touch with the account.
@goob it will be the user’s responsibility for now to clean up their old account. we’ll provide a message stating that but for now, it would just be much easier
and for the record, no, this decision was not made before. As you can see below, “Export pod data to an archive” was already decided upon, but I closed it early after Jay pointed me to the code that was already in master dealing with export archives.
I think this topic is being over complicated. Realistically, due to the distributed nature of diaspora there could be duplicate contact public names on different pods. The issue should be how to safely transfer from one Pod to another without losing touch with friends on the current and other Pods.
I have drafted simple proposal for transfer authorization. Please tell me your thoughts.
This is pretty much what I outlined, except for the additional email step. My proposal has the advantage that PodA could be (permanently) down when the transfer happens. And I’m missing a form of authentication against third parties in your proposal. How would you ensure that a rogue pod doesn’t simply announce that a user now lives at him (given he somehow managed to know a few contacts of the user)?
It is the job of PodA to announce to the contacts that the user has moved. PodB has no part of that process. The optional contact list I mentioned as part of the archive is just that, a list. It bears no ability to set up communication with the other pods unless manually executed. Whereas, the PodA contact update is automatic which friends’ pods will autoupdate to the new pod without interaction.
@samgleske That’s an awesome proposal, and I agree with the way it plans to carry out the ultimate goal of having fully-transferred, unobtrusive migrations from pod to pod in our own network.
That is definitely a good step in the right direction.
We just really need to focus on the authenticity of the data we let someone import. By which I mean I want to avoid people creating accounts and then spamming a server with fake imported user archives, thus opening a door for DoS. Also, I am not convinced our asynchronous protocol is set up to handle the handshake and communication necessary to establish what is outlined in step 3.
Also, I would at least inform the contacts of a user that has changed Pods about it, maybe even let them confirm it first. e.g. "Your contact ‘name’ has moved from ‘podA’ to ‘podB’. Please confirm."
Another possibility would be to display a move in the stream as a “special status update” for all of the users contacts.
Waiting for someone having the time to develop the whole solution, a temporary solution could be allowing to export and import a list of contacts. This would be only an handles list so no problem about identity or anything.
I’ve made a half-ready script that uses cliaspora and the existing export functionality. Due to way things work unfortunately cliaspora is not able to trigger a search for users not known for a pod, so it only works for users known to the pod where moving. Need to clean up the code also and somehow make it work, either by patching cliaspora or triggering a search outside it.
Should we create a working group to investigate and decide on the best approach to solving the account migration issue? It’s such a key issue to Diaspora’s success that I wouldn’t want it to fall on to the back-burner.
I think we have to put energy here, as joindiaspora / diasp.org become really too big. Allow users to move from a pod to another can solve a part of this problem.
Yeah, this is a huge priority. Bigger pods have to deal with more workers, and therefore more potential hiccups. If we can facilitate a way to easily and securely migrate to another pod, we could potentially address some of these network issues with federation, while also encouraging smaller pods to pop up.
As pointed there, I think we should at least provide a way to export and then import contacts (and with them, Aspects). I don’t see any downside with a simple json containing that, so we really should do it soon.
How labour-intensive would it be to code a simple manual migration process for now:
User exports their entire account data to a local file on their machine.
User creates account on new pod and imports account data file to new account.
Contacts are then informed that this person has moved from pod X to pod Y, and are asked to authorise connection to new account on new pod.
User is prompted to close their old account manually.
Just to get the possibility of moving one’s account, even if it’s not the tidiest method of doing it, as quickly as possible, while the exact method of creating a seamless transfer of the type Jonne proposes which is also secure is debated.
If an interim method isn’t going to be prohibitive in terms of coding effort, I could start a proposal on this, but I don’t want to do so before hearing from devs on feasibility.