Backup and restore – account migration

Features and Ideas
86
  • 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.

87

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.

88

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.

89

@jasonrobinson

It’s all part of the spec that I wrote that Senya based his crowd funding on :slight_smile: 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).

@goob

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 trust alice, that she has shared the post only to trustworthy persons
  • You trust alice, that she don’t leak your comment to someone else (now and in the future and in the backup)
  • You trust every other person (the person with whom alice shared the post), that they do the same …

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:

  • more complex
    • more error prone
    • takes longer to implement
  • less useful for the users
90

@supertux88

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 :slight_smile: 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.

91

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.

92

Hi, migrations will be useful but rare events. So I’d vote for the simple and lighter second approach.

93

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.

94

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.

95

but we don’t have polls with 1000 participants :wink: And we have also signatures in comments and likes, and compared to polls, the polls are smaller :wink:

So if I’m an active user with many posts (long history :wink: ) 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.

96

Proposal: Include polls & poll participations to users archive?

See the comment and further discussion.

Outcome:

Votes:

  • Yes: 9
  • Abstain: 0
  • No: 0
  • Block: 0

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.

97

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!

98

@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. :slight_smile:

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.

99

@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.

100

Does backup and restore concept include Pod Migration?

101

Here’s a simple import button without backend:
https://raw.githubusercontent.com/programizer/screenshots/master/importUI1.png

https://github.com/programizer/diaspora/tree/import_profile_gui_2

102

Rails console script gist for partial import:

103

In principle, yes. But Senya’s approach omits restoring after server death, so far. That’s why, I’d view backup and restore with regard to server deaths as a separate issue. See here:
https://wiki.diasporafoundation.org/User:Senya/Account_Backup_And_Restore#Description

104

Duplicate discussions, now closed:

Export data / Import data
Importing and exporting contacts through pods
Personal Data Import/Export
Import profile functionality - user request
Moving/migrating between different pods
Basic idea to move users between pods on D*

105

I know this is a very old discussion, but there seem to be still no real progress in account migration or even backup for a user so at least contacts are not lost when, for some reason, anyone decides to move to another pod.
A few weeks ago I saw this post that makes it possible for a ordinary user to at least have the contacts saved:
(permalink on my pod, replace the podname if for some reason you can not reach it)