Personal Data Import/Export

@jasonrobinson I’ve not looked at it in detail, just saw that it contains contact information, post information and one or two other things (I think, can’t remember now). When I said ‘it works’, I simply meant that the export button does still provide you with a dump - not necessarily that it was in any form which would be useful for importation elsewhere.

@rich1, now you’re in the swing with JSON, how about creating an export feature…? :wink:

I could write one in .NET - not sure it’d be of much use to anyone though?? Unless it’s externally hosted perhaps… Hmm… I’ll have a think about that :slight_smile:

@rich1 well it needs to be part of the d* core code - but if you have good ideas on the structure, feel free to create some specs on the content :wink:

//offtopic
Hey, new version of diaspora-tools out, Python script to migrate contacts across pods - a little more reliable now, uses fresh diaspy and also works out of the box with SNI SSL pods with Python 2.x (like my pod :P).

https://github.com/jaywink/diaspora-tools
offtopic//

As written down in my explaination: I’d go for JSON as it comes to contacts/aspects, since those are simply data.

On the other hand, posts are embedded in context, which XML can better map, I think.

When it is zipped anyway, why not split those information?

Hey! :slight_smile: What’s going on with the “import” feature?

Is it developing?
Cheers!

This is a really old topic and we discussed a lot to find out how to implement this feature but codewise nothing happened. I’d suggest that we divide the feature in some smaller steps so we can see some progress with less effort. The first step could be:

Implement manual import/export from the settings page including the following user data:
name, 5 profile tags, bio, location, gender, birthday, nsfw profile, searchable profile, language, show community spotlight in stream, email notifications

We will need two buttons: one to export the data (as json?) and another one to upload a file and overwrite the existing settings with the ones given in that file. Later we could let the user decide which profile information he/she would like to export/import.

The implementation should be easy and even could be doable for a newcomer (as long as he knows some RoR).

What do you think about this? Is it a good idea to divide the feature into smaller ones like I proposed or am I missing something?

Absolutely - small steps as all other things. Maybe we could make a master task with subtasks - that approach seems to have worked well with the UI rewrites?

@ruxton I think you we’re working on some parts of this - any progress?

I agree with @steffenvanbergerem .
The next step is enabling re-import of the existing .xml-profile-exports.

@mrfrety I am not sure if we really want that. Even the export we have right now looks broken to me and adding support for the existing xml files adds extra complexity. As a first step I’d prefer export and import of basic profile information. The next steps would be adding more information to the import/export feature and drop the old xml export as soon as we are able to export (and import?) all personal data.

I think there is just a small number of users who already closed there accounts and really need to import their old xml files. For those we could create a tool (separated from the diaspora* codebase) which converts the old xml file.

I made a new “meta issue” to track this whole thing with different smaller tasks - https://github.com/diaspora/diaspora/issues/5343

Plz feel free to work on any of these :slight_smile:

Posted my proposal regarding account backup and restore, ie migration. Comments welcome.

Nothing much happened in the Jasons post https://github.com/diaspora/diaspora/issues/5343 . I and many other community members want this feature desperately and we all remember that backing up and shifting house to another pod was promised by diaspora* long back.

Im commenting here by assuming that with personal data import/export, we also mean pod migration.

This, is a critical issue for a decentralized network:

Biggest issue with there being no pod migration is that if the pod i
am in goes bust, my account, connections, everything go bust.

that practically kills all the purpose of decentralization.

as long as i am locked into one pod, i am on a centralized network.
content spreading in a decentralized fashion does not make up for it.

as appalling as it is, i can trust that my account on facebook will be
there for a loooong time. even if they use my data as a means to
profit off of me by selling it to government and advertisers, that
also ensures continuity of my account.

but with diaspora, i am obliged to trust the effort of a small group
of people or even one person setting up a server somewhere and then
being able to maintain it through the years. which can go bust at any
time due to a million reasons.

if, somehow, an established organization with endurance sets the
server up (ie a corporation, a ngo etc) i have to be wary of their
motives. yeah that’s a great diaspora server with tens of thousands of
users, but it can even be a front by an intelligence organization to
spy on their users - they do it with tor.

or i can set up my own server, and have to deal with everything that
comes with setting up and maintaining a server. which, many of
diaspora users cannot do.

or i can use the apparently not so mature p2p client and battle with
many issues.

@unity100 that’s why this is one of the highest priorities for the project, and why community members contributed €4750 towards the development of this important feature. You can follow the current progress of development via the #senyadiasporaaccountmigration tag.

thats great to hear, goob. i already have a wide social circle on diaspora, but the fact that i wouldnt be able to move my account if something happened was considerably discouraging me from using it as my main social service.

i look forward to this feature.

It is taking a long time to complete it properly, because it is a very complex mechanism to produce a migration feature which is both secure and easy to use, but it is absolutely one of the highest priorities for development.

Closing this in favour of the active discussion.

1 Like