You may say it’s not important, but I’m sure it would result in issues reported like “I migrated and lost all comments to my posts! How can I unmigrate back, please?”
Better than them currently saying “I lost my account due to the pod I’m on disappearing, how do I restore my identity?”.
Start off small, expand later…
Would it be technically feasible, when someone migrates to a new pod, to send a message to people who have participated in conversations with them asking whether they are happy for their comments to be stored on this new pod?
It could work something like this:
This means that in this case some comments are not available to Alice on her new pod, but I’d imagine that this case where someone denies their comments to the new pod will be rare as it would probably only happen if there was a pod with a bad reputation. So this would, in most cases at least, enable complete conversations to be hosted and available on Alice’s new pod while respecting the privacy and agency of the other participants in those conversations.
Would that a) solve the concerns about privacy and b) be technically feasible?
I think we need to make clear for what we want to use this archive?
Also still think it is not a good idea to include content into the migration archive.
and
Better than them currently saying “I lost my account due to the pod I’m on disappearing, how do I restore my identity?”.
How would you restore the account out of an archive without content if the pod doesn’t exist anymore?
Would it be technically feasible, when someone migrates to a new pod, to send a message to people who have participated in conversations with them asking whether they are happy for their comments to be stored on this new pod?
There is so much that doesn’t work properly with your “solution”, in my opinion this creates more problems than it solves. We need a simple solution that everybody can simply move to a new pod, without extra barriers.
If I have my own pod, I can move it (and with it my profile and all posts and comments from all users) to wherever I want and I don’t need to ask everybody. But if I don’t have my own pod (but want to move to my own pod), then I need to ask everybody?
Also: If you write a comment on another users post, he don’t ask you, if he can federate your comment to all other users that can see that post.
I think we need to stop the illusion, that you still have full control over everything after your data left your pod. When other users can see your posts/comments, then they can do whatever they want with it (does not mean that they do so, but the could). And yes, bad guys can do bad things (publish your private posts/comments), but I think that is no reason to create a broken unusable migration-feature for all good guys.
Another way could be (but that’s just an idea and I do not know if it is a good one…) : add a binary info to each comments depending on an option in the setup page of the person who comments, saying «I agree to migrate my comments on a new pod if a contact migrate to this new pod». When doing the migration only post with the flag should migrate the others being retracted and replaced by “comment missing here”. Would this be technically feasable and do not add too much complexity ?
How would you restore the account out of an archive without content if the pod doesn’t exist anymore?
It’s all part of the spec that I wrote that Senya based his crowd funding on 
I have no knowledge what the current situation is, whether the mentioned automatic backup is even planned to be implemented, but it’s totally doable.
Btw, just saw two more pods announce going offline with a very short warning notice. The whole migration feature will not help at all if there is no automated identity backup. Only 1% of people will regularly download their archive just to backup a service they are using. I know I never do. Why? Because service providers do it for me. Diaspora can be thought as a big service provider composed of many nodes.
But this discussion has been taken already, I’d rather not start down that road again…
- where would you store the comments before they are stored on the new pod? should the user import the archive a second time, after the users all accepted that the comments can be stored?
As I said, ‘Bob is happy for this to happen so clicks OK. His comments in the private conversation are then sent from his home pod to Pod Y.’ His comments are stored on his home pod, and sent direct from there.
- the discussion was about comments on posts, that could be hundreds of users that need to be asked?
Apologies; I’m sure I had read that this related specifically to conversations.
Also: If you write a comment on another users post, he don’t ask you, if he can federate your comment to all other users that can see that post.
That’s a choice that I make when I comment on a post; I implicitly authorise it to be shared with those with whom it has been shared. However, it shouldn’t subsequently be shared with further people, which is why it is not possible to retrospectively make a limited post public.
All I have done is shared an idea that might help enable migration of remote users’ comments while meeting the concerns of those who voted against the proposal. This procedure I suggested with comments is, as I understand it, the same as what would happen if Bob and Cath were in Alice’s contact list (a notification asking for confirmation that they are happy for their user details to be hosted on Alice’s new pod). If that is not how the migration feature is being implemented, then I would be less happy about it being implemented.
add a binary info to each comments depending on an option in the setup page of the person who comments, saying «I agree to migrate my comments on a new pod if a contact migrate to this new pod».
This wouldn’t work from my point of view. I would, for instance, be happy for my comments to be migrated to a pod run by someone I knew, but less happy if Alice was moving to diaspora.dodgy-identity-thieves.com
It’s the choice of whether to allow your comments to be moved to a particular pod which is at issue.
It’s the choice of whether to allow your comments to be moved to a particular pod which is at issue.
Not necessarily. If you do not trust you would select that you do not agree to migrate you’re comments to another pod (be it trustable or not), if you do not care you would agree.
It’s all part of the spec that I wrote that Senya based his crowd funding on
I have no knowledge what the current situation is, whether the mentioned automatic backup is even planned to be implemented, but it’s totally doable.
But this automatic backup should contain the same data as the manual backup, so it also needs the comments (and other additional metadata).
As I said, ‘Bob is happy for this to happen so clicks OK. His comments in the private conversation are then sent from his home pod to Pod Y.’ His comments are stored on his home pod, and sent direct from there.
And if the pod of this person doesn’t exist anymore (because maybe the person was on the same pod as you, when your pod disappeared?) , it is not possible to restore the data?
That’s a choice that I make when I comment on a post; I implicitly authorise it to be shared with those with whom it has been shared.
But you don’t know with whom the post has been shared? Maybe your comment is already on diaspora.dodgy-identity-thieves.com because the post author shared it with a person on this pod. You don’t know it, you don’t see it, you can’t control it. So you are trying to control something, where you don’t even have control when you write your comment.
If you write a comment on a post from alice, you trust alice, that alice shared the post (and your comment) only to trustworthy pods (you can’t control it). So why don’t you trust alice when she wants to move to another pod?
@all
why do you try to control something where there is no control? This only makes this feature less usable, but doesn’t stop anybody to do bad things if he wants to. If you write a comment on a Post on Alice:
You don’t have control on anything when you write the comment (you need to trust alice) … why do you try to imagine to control what alice could backup? If alice has her own pod, you also don’t have control on how alice backups here database and where she stores the backup and what and how she restores the database-backup on another server?
Everything you try to imagine control where there is no control only makes this cool and useful feature:
But this automatic backup should contain the same data as the manual backup, so it also needs the comments (and other additional metadata).
No it doesn’t, at least not in what I wrote I never wanted content included in the automated backup archives - that would make the whole system too heavy.
But as said, that ship has sailed, for the current plans I don’t know.
Ok, the next important point to raise. What do we do to the polls on export/import/migration?
Just ignoring a poll is not an option since this will result to the broken UX. After migration, user would see his posts where previously were polls without them or with messed voting.
First option is to include everything to the export archive required for polls to keep working after archive import: polls themselves, poll answeres, poll participations. But there is a nuance: I don’t know if it is a design decision or just random, but now it’s impossible to check who voted for which answer. If we export the archive there will be each vote in the archive with the ID of the voter. So it’s gonna be less private this way. On the other hand, an owner of an own pod is able to see this info anyway, so it’s not generally protecting privacy.
Pros: polls are alive after users migration
Cons: much metadata must be included to the archive resulting in possible bloat
Second approach is to lock votings when user migrates. Correct me if I’m wrong, currently it’s impossible to close a poll for new votes. If we introduce such a feature, we can include only number of voters to the archive and close voting on migration.
Pros: votings still looks nice; archives are lighter
Cons: it’s impossible to participate in old polls anymore after a migration
Please share your opinions before I start any proposal.
Hi, migrations will be useful but rare events. So I’d vote for the simple and lighter second approach.
I think it’s better to include everything to the archive.
Cons: much metadata must be included to the archive resulting in possible bloat
I don’t think that that is a problem, because only a few posts contain polls, and also polls are not really big.
Biggest thing is not polls themselves, but poll participations, each one must include GUID and author_signature.
One poll participation is ~300 bytes, for 1000 participants it’ll be ~300kb and compressed notably lighter.
but we don’t have polls with 1000 participants 
And we have also signatures in comments and likes, and compared to polls, the polls are smaller
So if I’m an active user with many posts (long history ) with many participations (comments, likes and polls), then the archive could be some MB, but this should not be a problem. If I have uploaded some photos, I think the photo-archive is bigger.
Proposal: Include polls & poll participations to users archive?
See the comment and further discussion.
Outcome:
Votes:
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
But there is a nuance: I don’t know if it is a design decision or just random, but now it’s impossible to check who voted for which answer. If we export the archive there will be each vote in the archive with the ID of the voter.
I’m surprised to hear that this info is federated by the polls feature. I don’t think there’s any need for anyone except the poll creator to be able to see who voted for which option. I would vote for closing this down so that only poll question, poll answers and number of votes for each answer were federated. But this should be shut down within the polls feature code rather than in the export code. That way exports will be lighter!
@goob: the author of the poll-participation is federated to validate the signature and also to prevent duplicate votes by the same person. And if only the poll-creator sees who voted and sends only numbers to everybody else, he would be able to fake the result. Maybe we should simply make the poll-participants public visible to everybody (like votes here on loomio). But this needs its own discussion and doesn’t belong to the export.
Also the proposal here is only about including the poll and answers to the poll-creators export. The poll (and answers) is not included to other persons export.
@supertux88, thanks for your reply. I couldn’t (and still can’t) find any indication that this vote relates only to migration by a poll creator, but if so, I think it is important to migrate all data necessary for a poll to work, so that a poll (if still open) can still be work.
It would be good to refine the polls feature with things such as the ability to close polls (and to create them to be open for a limited time only), and to look at ways to reduce the federation of user data when interacting with a poll, if this is appropriate an useful. All this would make the migration of an account including polls more streamlined, but this work doesn’t belong to the migration feature. These refinements would be best added to, and discussed within, the Enhancements for polls feature issue in Github.
Thanks again.
Does backup and restore concept include Pod Migration?