So we have User and Person models. On migration we must create a new user but do we preserve the same Person model which was known for that person? I suppose we should.
Yes, we should keep the same Person as it is the same identity, just moved local instead of remote.
I don’t think posts and comments can be ignored. It is possible that the new pod doesn’t contain some posts (especially private). I believe it must not be dropped and we should fetch them on restore also.
Well, it’s not feasible to import posts or comments imho. What purpose would that even solve? Your contacts would not see any of the uploaded private posts unless you also push them out to them - which would be bad because they already have them from before.
The main point is to save the identity, not every crumb of data related to it.
Where do we store signature? Don’t we have to have a separate field in the schema for that?
This would be the same signing method we use for delivering content - ie the receiver only accepts it after verifying the signature in the payload against the public key of the person. Whether this should live in the diaspora federation gem where the code is readily available is up to question. I’d say no, but of course it would be easier to implement that way. I don’t consider this part part of the protocol as such, but then that is not in any way under specification anyway.
I think it is not frequent enough. Some people post frequently, and one week would be a huge loss for them. How about making that adjustable according to person’s activity level? Or simply backup every day if there were changes. If there weren’t, don’t backup at all.
I believe this can be left as detail when the thing actually works. If we leave out posts and comments, which I think is the only real way to do it, then there is absolutely no sense in sending backups daily.
I also beleive we must support some kind of limitation for pods backup capacity. For example a pod wants to store backups, but no more than for 100 people. Then it shows that it doesn’t receive backups anymore, but previous still work.
Again, if posts and comments are not part of the archive, it will always be very small. Additionally, backup pods would be randomized, guaranteeing some balancing of load between pods. Of course we can introduce a setting like this, but personally it doesn’t sound super useful, considering how much data pods store normally compared to how much this would add.
One interesting case is what happens if the pod has turned off sign-ups in the event that someone wants to restore? I think we should bypass the sign-up not being on and let the user restore. This would speak towards the setting you mention, so that pods don’t gather too many possible identities that could activate suddenly.
Great comments, thanks!