Hacker News Reader

Comment by kijin | Hacker News Reader

Exporting your personal data is only half of the story. Importing is the other half.

Suppose I exported all of my posts, photos, contacts, and a bunch of metadata from social network A. Perhaps I could view the contacts in Excel and browse the photos in my favorite gallery app. But unless I can upload it all to social network B and continue as if I've been using B all along, the data is not really "portable". It's just a backup, a frozen snapshot that can't be unpacked anywhere else.

I'm not even sure if it makes any sense to import one's Twitter feed into Instagram or one's Facebook profile into Reddit. Edit: I'm not saying this is because of anti-competitive behavior on anyone's part. The services simply are so drastically different.

View on HN

As you say, the data domains of different services may simply be logically incompatible, which is fair enough. As critical as I am of social media platforms, I don't think they should have any obligation to implement the abstract ability to "import" data in general. As long as they provide their users with the ability to export their data in a reasonable fashion, in a well-defined and consistent open format, and as parseable as technically feasible, I believe they have done their duty.

What's important is that a Twitter, or Facebook, or Reddit alternative should be able to implement data import from their respective competitor, without facing intentional anti-competitive difficulties. Let "the market" decide which services want to implement the import of which kind of data.

Absolutely. Service providers have a real incentive to implement _import_ functionality, since it means an opportunity for new users on the platform.

Since the incentives for the service providers line up with the users, I don't see a need for the government to regulate importing data.

Export is the exact opposite. The incentives for the service providers go directly against a user. After all, if the provider export a use's data, then then that user can just leave!

Where this is a real need, something will come up - somebody will develop a service, a utility that can be a bridge between the exported data and the new target. Without the export, this would not even be possible.

> Exporting your personal data is only half of the story. Importing is the other half.

If we're wishing for things, I'd like to add the ability to have "live" exports/imports. By that I mean two services with comparable data types should be able to keep your accounts in synch, such that a change made on one service is reflected (after only a short delay) on the other service.

You would still have to visit Facebook if you wanted to see what your friends there were saying, but they would be able to see what you were posting on Mastodon, for example, without needing to create a Fediverse account.

Putting a square into a round role does not make sense, but you may now be able to design a compatible square or round hole that one can move to.

On the other hand every single app at one point would happily import your contacts no matter how they were formatted...

The incompatibility is by design.

Contact data is relatively uniform - you got names, addresses, phone numbers, maybe a few dates. Even with the handling of different addresses per contact, different systems already show divergent behaviour, even when they use the vcard standard.

This becomes immeasurably more difficult with information from, let's say, Amazon: A competitor would not have the articles I've viewed, or the comments I have left under questions, or a compatible rating system.

Even social networking sites ... how useful is it to import twitter exports of my tweets answering to someone if neither that someone nor the content I answered to is available in the target system?

Sometimes, it is by design - in the majority of cases, it's just different people implementing different use-cases differently.

Without something like the GDPR, incentives are very different for exporting vs importing: Import functionality makes it easier for someone to switch to your service, while export functionality makes it easier for someone to switch away.

Additionally, if a service is missing import functionality, you can choose to not use it. While you'd often only realize you need export functionality while you've already used a service for years.

Maybe the case of porting data between social media services doesn't make much practical sense, but there are many other services where it does. Fitness tracking apps as an example - you'd likely want to take your history with if you switch services.

And usually these services would not be using the exact same data format for import vs export. But that's not as big an issue in practice - you'd often find third-party scripts or services that can do the conversion for you.

Data from a popular social network is gold.

Other social networks would implement import functions in a day.

The gdpr actually says that data should be automatically transferred from one controller to another where technically feasible. https://gdpr-info.eu/art-20-gdpr/

Reply on news.ycombinator.com