Backup and restore – account migration

I also would recommend not to encrypt the data; however it would be good to tell users, that the data is unencrypted and should be kept in a safe place before downloading.

@bradkoehn Blocking proposals is only valid if the proposal itself is invalid, which it is not. Please don’t block, but disagree.

I’m going to abstain from voting because I’ve had next to zero participation in the whole backup/restore conversation. And I feel like there are people here who know better than me what should happen. But I have this to say:

Isn’t this why we use https? So that files are transferred over encrypted lines? I think it would just introduce another layer of complexity, for not much benefit.

And correct me if I’m wrong, but if you were going to send an encrypted archive, it would have to be encrypted on the server side…using keys generated…somewhere; either locally or on the server and they’d have to be sent over the same (again, already encrypted) lines we’re worried about someone tapping. I’d rather just do all of it locally.

I’ve just repeated what other people have already said, and probably poorly. So, my current recommendation is no, but I’m not an expert so I’m not voting.

Maybe encryption should be optional?

Blocking proposals is only valid if the proposal itself is invalid, which it is not. Please don’t block, but disagree.

When was that decided, Dennis? My memory is that the decision was that a ‘block’ was considered a ‘strong disagreement’ and no more. At the moment the only proposal regarding this that I can find is this one. I’d be grateful if you’d point me to the proposal which changed this so that I know the current situation. Thanks.

When was that decided, Dennis?

Actually, good question. That’s how we handled in the past. Do you feel like we should write an official documentation?

This says:

Block does not prevent the proposal from passing; it is simply a strong message that more discussion might be needed.

So I shall be wrong! Sorry. :slight_smile:

Oh, thanks for finding that, Senya. I knew I’d read it somewhere!

Proposal: Include comments of other people to the user’s data archive

We have the feature request for this. The user’s data archive which we export now includes only user’s own comments. But if we want to import posts with comments from the archive, the comments won’t look consistent unless we also include other people’s comments for that posts to the archive. However it maybe viewed as data safety violation. Whether we should add other people’s comments to the user data archive?


Outcome: Proposal passes, comments will be included in the user’s archive.

Votes:

  • Yes: 12
  • Abstain: 3
  • No: 3
  • 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.

To comment on a limited post means you trust your friend and his podmin. With this proposition, a user can change his pod, and you will be forced to trust the new podmin for the old data you posted. On another hand, you haven’t access to your friend contacts anyway so you don’t know with which pod the comment is shared initially, and the whole model of diaspora* is based on the assumption that you trust your friend, and your friend trust his podmin, so the situation seems not worse here than before. The only case left is how the user will store the archive. I’m wondering what Facebook does? Does it include friends comments in the export?

I’m wondering what Facebook does? Does it include friends comments in the export?

It may have changed since I did it (more than 1 year ago) but it didn’t saved any comment (either your comments on other’s messages nor friends comments on your messages).
Note that Facebook export was not intended to import the profile elsewhere later.

Restoration of comments is a re-publication. Publication of another user’s content and/or publication in the name of another user, both being the case when restoring comments, needs the consent of the user in question. Comments of users not consenting to this may be replaced by a content-less placeholder indicating that there was a comment, but it is no longer available.

one suggestion, for including others’ comments in the backup without any privacy violation, is to add the following option to Diaspora:

  • when we want to publish a new post on diaspora there’s an option to limit its visibility. in the same way introduce a similar option while commenting to allow the user to declare the comment as “Public” (which says that the OP is free to download/export/restore this comment) or “Private” (which says that this comment should not be downloaded/exported/restored).

the above option only works for the newer comments after such a feature is introduced. to deal with the existing comments, i think one should be allowed to backup others’ comments but should not be allowed to restore the same without the consent of everyone included.

Proposal: For other peoples comments include guid and author’s pod, but not the text and diaspora ID

Since people might not be happy about including their comments in the export archive, let’s not do it! Lets include the guids of the comments and the pod where the author lives. With this information it will be possible to fetch the comments from the other pod if such thing is allowed. Thus the decision whether it is allowed or not to have the comments out is decided by the author’s pod and is out of the backup/restore feature scope. For example, fetch of the public comments is allowed without any conditions, and of private comments is allowed only if you are on the pod which has imported the archive of the previous user and can prove it. Moreover, having the guids may be used to render stubs in the discussions like “there are 4 comments in this discussion that are not available to you”. This will make a difference between the case where there are no comments and the comments are missing for some reason (weren’t fetched or were retracted).


Outcome: I was wrong opening this proposal, because the previous one actually had passed. If you feel disagreement with the decision, please say it in the discussion.

Votes:

  • Yes: 3
  • Abstain: 2
  • No: 3
  • 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.

The migration should be an easy way to move to a new home. It should provide the same experience (as much as possible) on the new pod, as on the old one (hopefully better performance/stability/uptime). But if I break all my own posts (and conversations in comments on my posts), it is really “useless”.

Also fetching is not a solution:

  1. I would create really high traffic if you fetch every comment from one of your posts.
  2. It is not possible now to fetch private stuff. (and it is also not possible to fetch public posts know, but this could be added easily)

Why do we need to prevent someone to export data, that he is allowed to see? Everywhere else we handle it the way that the post author is the “owner” of the comments (and likes and everything else attached to the post). He decides who can see this stuff. Why handle this different at export? Everyone can take a screenshot of the comments or copy/paste them. So why should we maim a great feature
only to promise privacy, which is not there? If there is an API someday, it would be really easy to create a backup of all comments, but also now I can create a script that backups all comments (and if my new pod is my own server, then I can even import everything in the database).

This whole stuff only makes things worse and harder for those who simply want to move to a new home and don’t want anything bad. But it prevents nothing that someone who wants to misuse it can do bad stuff with data of others. There are still many possibilities to do bad stuff, and we can’t do anything against it. It’s the same as with the whole copy protection and DRM, the good ones get the disadvantages, but it can’t do anything against the bad people.

If someone really has a problem that the post author (and everybody else who can read the post/comment) can do “whatever he wants” with the comment, he should rather not post stuff on the internet!

I mostly agree with you, but there is a little difference between copy-paste (or downloading with API) and exporting, since in the archive there must be the comment’s author’s signature, and by having a signature you can prove to a 3rd party that the person actually said these very words. And you can’t prove the authenticity of words with screenshot or copy-paste.

If I have my own pod, I can also prove that the person actually said this (export signature from the DB), or if you enable fetching for comments, it also contains the signature. You can not prevent this without removing the signature (which would be a really bad idea :wink: )

But I think this is an advantage, because you can only export/import the exact same words that someone wrote (except that a podmin can always manipulate stuff on his own pod, but this has nothing to do with this topic).

Again, if someone has a problem with that and can’t stand to his words, he should rather not post stuff on the internet …

On a distributed network, where you send everything to other servers, you never ever have full control on that data again, and we should not promise that here. There are multiple other ways to export and prove stuff, which are by design.

Okay, I wasn’t right about opening a new proposal, since “A proposal is passed if there are more Yes votes than No and Block votes together”. But it would be nice to discuss another option anyway.

Hi, including the comments are all right for me as there is many other ways to save publication and its comments. However the questions I’d like now to be discuss here are the following (but maybe I do not undersand how things works and these question will be irrelevant ?):

  • If I have commented on a post, and the owner of the post migrates, will I be able to delete manually (or by closing account) my comments on the same publication after its migration ?

  • it raise another question to me : will I be able to find the post easily ? (say, if I have bookmarked it, will the adress be still connected to the new place of the publication (with a redirect maybe ?) Will the GUID of the publication be changed (if I had bookmarked the adresse with the GUID instead of the local number) ?

If I have commented on a post, and the owner of the post migrates, will I be able to delete manually (or by closing account) my comments on the same publication after its migration ?

As I said there comments deletion is not very precise wording for the federated web. You can’t be sure the foreign pod is not modified to ignore retraction messages. It’s better to say comments retractions. Considering that, yes, retractions will be routed to the new pod.

it raise another question to me : will I be able to find the post easily ? (say, if I have bookmarked it, will the adress be still connected to the new place of the publication (with a redirect maybe ?) Will the GUID of the publication be changed (if I had bookmarked the adresse with the GUID instead of the local number) ?

There is no need to change neither GUID nor local id of posts in the migration process. It just updates owner reference.

This just makes the whole process more complicated than it needs to be and provides little on top of the most important task.

Well, I guess breaking conversations is not what people expect from the migration process. 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?”