Inter-Pod Seed Migration
Patrick Michael Niedzielski
I'm Patrick Niedzielski, a student at Phillips Academy. Recently, I've
been looking to set up pod on our student server, available to students
of the Academy, but both I and a number of other students already have
accounts on joindiaspora.com. It's come to the point where I need seed
migration between pods, and so I've decided to take a stab at this
myself.
There's been a little bit of discussion about this, especially recently:
Diaspora Discussion: https://joindiaspora.com/posts/506169
GitHub Issue: https://github.com/diaspora/diaspora/issues/908
I've enough experience at programming (C/C++ and Perl, specifically),
but very little in Ruby (I read a book about it, yay!). If anyone wants
to help out, please send me an email. There are two other people
interested in working on this project as well.
*********************************************************************
The idea I personally like the most is the idea of a wizard to easily
move data:
1. User is on pod A.
2. User creates new seed on pod B.
3. User navigates to pod A, goes to some wizard UI to push
everything to pod B.
4. Pod A sends out notifications that User is now on Pod B, with
account x...@podb.eu.
5. All friends of User will have to accept or decline the move
notification, based on whether they accept the pod User has
moved to. This will allow them to keep control over where they
send their data. As long as it's pretty brain-dead, I think
this could be a good balance between ease-of-use and privacy
awareness.
I did think of having Pod A saving and forwarding messages to Pod B, but
this wouldn't give users the opportunity to make sure that Pod B is not
a known data mining pod, with which they would loose control of their
data.
If Pod A goes down, though, before the move, all data that wasn't
exported would be lost, and users couldn't move pods.
Another idea is to make redirection accounts. Say User is on Pod A at
x...@poda.ca, and User moves to x...@podb.eu. By this means, instead of
deleting account x...@poda.ca, all messages sent to it, all URLs created
while it was active, and all links to this account would redirect to Pod
B. My problem with this is, again, data mining. If Pod A is malicious,
it still receives and mines data from users. The move wouldn't have
much point then. Also, if Pod A goes down, contacts who point to it
would have no way to move to the new Pod B account. This wouldn't work
on its own, and I'm a tad afraid of the scalability issues of keeping
every old account around, forwarding to new accounts, which themselves
might be forwarding, ad infinitum.
A final idea is to use the existing export feature, adding a restore
function. It's a really interesting idea, and it guards against the
problem of Pod A going down listed above, but it brings with it an
important problem: what if someone gets a hold of your exported account,
loads it to another pod, and either has another account will all your
information, or moves your account so you can't use it? There probably
is a way around this, but it also seems a little less user friendly.
Perhaps the wizard could automate that last process.
There is also a lot of talk about data redundancy, but that's something
huge I'm not willing/don't have time to implement, something that has
many problems associated with it, and something that should be given
extremely careful thought, and might require a redesign. There's some
conversation about it on the Diaspora post linked above. Feel free to
talk about it here, but know that it's not going to be part of my
contribution. :)
*********************************************************************
Any thoughts/comments/questions/puns/freshlybakedgoods/davidbowiealbums
would be great; please reply onlist with them!
Cheers,
Patrick Niedzielski
Joux
I've already tried to write some lines on this from a user perspective
[1] some weeks ago. I was thinking about a pretty simple "permanently
moved" message approach. Thanks for bringing this up again.
Having read a little about the D* message protocol [2] now, I think the
encryption key handling is crucial. Not only do we want to
a) let users that follow the moving user if they want to communicate
with the new pod
but also
b) let the moving user decide they don't trust the old one anymore, as
you've suggested.
For b) it would probably make sense to generate a new keypair on the new
pod, as the old one could have kept the private key. This means that
messages being sent must now be encrypted with the user's new public
key, meaning that friends' pods must know about the pod change. Simple
forwarding by the old pod won't work. But as we want senders to actively
choose to accept their friend's move to the new pod (as of a) ) this
step is necessary anyway.
I think your concept already works pretty well:
> 1. User is on pod A.
> 2. User creates new seed on pod B.
> 3. User navigates to pod A, goes to some wizard UI to push
> everything to pod B.
> 4. Pod A sends out notifications that User is now on Pod B, with
> account x...@podb.eu.
This notification would still be signed with the user's private key from
pod A, saying "x...@podb.eu" is the legal successor of this account.
> 5. All friends of User will have to accept or decline the move
> notification, based on whether they accept the pod User has
> moved to. This will allow them to keep control over where they
> send their data. As long as it's pretty brain-dead, I think
> this could be a good balance between ease-of-use and privacy
> awareness.
>
> I did think of having Pod A saving and forwarding messages to Pod B, but
> this wouldn't give users the opportunity to make sure that Pod B is not
> a known data mining pod, with which they would loose control of their
> data.
>
> If Pod A goes down, though, before the move, all data that wasn't
> exported would be lost, and users couldn't move pods.
>
Here's an idea for the "pod A goes down" scenario: the user has backed
up their private key from pod A. On pod B they use a function in the
wizard UI called "send move notifications". This wizard needs 2 inputs:
- the backed up private key from pod A
- a list of D* accounts to notify
The wizard will create a move notification, containing the old and the
new account, signed with the old key and send it to all specified
contacts. The rest of the procedure is the same as you outlined above.
This way, people who have not recently exported their account data
before the pod goes down, can still recompile their friend list manually
and get back in touch.
Is this what you had in mind by adding a restore function to the export?
I think this would work, users would only need to be told "this _is_
your account, guard it well"
Best
j
[1]
http://groups.google.com/group/diaspora-dev/browse_thread/thread/a75a98e829c7546f#
[2]
https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol
Patrick Michael Niedzielski
On lun, 2011-10-03 at 00:59 +0200, Joux wrote:
> Hi Patrick,
[snip]
> For b) it would probably make sense to generate a new keypair on the new
> pod, as the old one could have kept the private key. This means that
> messages being sent must now be encrypted with the user's new public
> key, meaning that friends' pods must know about the pod change. Simple
> forwarding by the old pod won't work. But as we want senders to actively
> choose to accept their friend's move to the new pod (as of a) ) this
> step is necessary anyway.
This is a good idea. I think, if we have the user create his new handle
on Pod B the normal way, this would be pretty automatic. We'd have to
get Pod B to send Pod A the new public key, which would then be
distributed to all of the user's contacts, but that doesn't seem like a
major technical hurdle.
> Here's an idea for the "pod A goes down" scenario: the user has backed
> up their private key from pod A. On pod B they use a function in the
> wizard UI called "send move notifications". This wizard needs 2 inputs:
>
> - the backed up private key from pod A
> - a list of D* accounts to notify
>
> The wizard will create a move notification, containing the old and the
> new account, signed with the old key and send it to all specified
> contacts. The rest of the procedure is the same as you outlined above.
>
> This way, people who have not recently exported their account data
> before the pod goes down, can still recompile their friend list manually
> and get back in touch.
This feels like a good candidate for an internal API of sorts between
pods. I'll want to work this out on paper, exactly what an optimal API
would be between pods, hopefully for tomorrow.
>
> Is this what you had in mind by adding a restore function to the export?
> I think this would work, users would only need to be told "this _is_
> your account, guard it well"
Not exactly, but it's a good point to bring up anyway. It seems to me
that we'll have two ways to migrate:
1. Wizard UI on Pod A. Pod A sends out migration notifications
using its private key. Pod A sends to Pod B all old posts and
contacts, and Pod B immediately begins sharing with all old
contacts.
2. Manual UI on Pod B. Pod A has gone down, but the user has
backed up their data (and we'll want to add contacts, aspects,
and private key) from Pod A using the Export button in the
Diaspora settings page. Posts are restored for the user on Pod
B by uploading the file. From this, migration notifications are
sent to the contacts saved in the backup file using the Pod A
private key.
Is there any (preferably simple) way, though, to make migrations more
transparent with regard to posts? After the migration, all comments on
the user's old posts will not reach Pod B. I need to take a look at the
database set up to see if it is feasible to change the owner of the old
user's posts, but it seems to me that there will be problems. Anyone
with experience on the Diaspora databases have any ideas about this?
Cheers,
Patrick
elf Pavlik
> but very little in Ruby (I read a book about it, yay!). If anyone wants
> to help out, please send me an email. There are two other people
> interested in working on this project as well.
i would like to work on data portability in general, across various platforms for example, don't know all the inner workings of *dia but have quite a good grip on used protocols and have used ruby for a while...
i also haven't read in detail all the solutions proposed in this conversation...
myself i would like to analyze moving accounts on a level of webfinger which makes it not *dia specific, than look how to extend it for any custom needs.
also try to take advantage of PGP for signing 'moved to', plus all the existing infrastructure of PGP key servers, not forgetting again non *dia specific advantage
cheers!
~ elf pavlik ~