The Data Transfer Project was formed in 2017 to create an open-source, service-to-service data portability platform so that all individuals across the web could easily move their data between online service providers whenever they want.
The contributors to the Data Transfer Project believe portability and interoperability are central to innovation. Making it easier for individuals to choose among services facilitates competition, empowers individuals to try new services and enables them to choose the offering that best suits their needs.
Current contributors include: Facebook, Google, Microsoft, Twitter
Tag: data portability
🔖 The Data Transfer Project google/data-transfer-project
The Data Transfer Project makes it easy for people to transfer their data between online service providers. We are establishing a common framework, including data models and protocols, to enable direct transfer of data both into and out of participating online service providers. http://datatransferproject.dev
cross reference: https://boffosocko.com/2018/07/22/data-transfer-project/
👓 Instagram import in Micro.blog | Manton Reece
Micro.blog for Mac version 1.3 is now available. It features a brand new import feature for uploading an archive of Instagram photos to your blog.
This is an awesome development. I do wish it wasn’t so MacOS-centric, but hopefully its one of many export/import tools that shows up to improve peoples’ ownership and portability of their data.
👓 Customer acquisition on social media — with your own data | Marketing Land
Marketing Land is a daily, must-read site for CMOs, digital marketing executives and advertising campaign managers.
🔖 Stamp for music playlist portability
Stamp moves tracks and playlists across various services - Apple Music, Spotify, Google Music and others!
How awesome this portends to be! I’ve been wanting this type of functionality for a long time. I’m curious how long it stays up?
Too many music services don’t make it easy to transport your playlists as it’s one of the methods they use to lock you into their service (and their recurring subscription fees). It looks like it supports .csv formats, but it would be nice if there were a better standardized data format to let users own all of their own data. How great would it be if I could maintain my own playlist on my own website and then authorize services to access it to play what I wanted? Then I could have one central repository and take it to any subscription service out there.
It looks like it supports Spotify, Apple Music, Google Music, Pandora (Pro only?), Amazon Music, Groove, YouTube, rdio, Deezer, and Tidal.
Getting data out of Medium
Controlling my data is important to me. It’s also important that my students (and the faculty that I support) have the ability to control their own data, as well. That doesn’t mean that everything needs to live on a Domain of One’s Own. But it does mean that I want my data to be as flexible as possible, and as easy to move around as possible.
It’s really easy to download an archive of your Medium posts. Like your Twitter archive, you can just unzip the archive and upload it to your domain, and you’ve got it up and running.
However, if you want to incorporate those posts into a different platform — like WordPress, Jekyll, Known, etc. — it is more of a challenge.
I wrote my posts on the Medium API directly in Medium. Partly as an experiment, and partly because I love the Medium post editor. (It’s why I incorporated a Medium editor clone into Peasy.) But after writing three posts — complete with feature images, inline images, and code blocks — in Medium, I decided to import them into my Jekyll/GitHub Pages site. That’s turned out to be a challenge. Not an insurmountable one, but one that I’d rather avoid going through.
I downloaded my Medium archive, used Pandoc to convert the posts from HTML to MarkDown, and then copied and pasted the MarkDown into new posts on my Jekyll site. There was more post-processing than I anticipated, or would like. And it doesn’t look as easy to automate the cleanup as I would like.
Even more frustrating was my discovery a couple weeks ago that the Medium API supports posting to Medium, but not retrieving posts from Medium. It is easy to write code that cross-posts from another platform to Medium, but Medium makes it more difficult to go the other way.
Why?
My guess is that their focus is on content. They want to be the place where we go to find ALL THE CONTENT. So they make it really easy to get content in. Harder to get content out. And by making a beautiful, easy-to-use editor, the temptation is strong to just use Medium from the start.
If we just want to write, get our writings read, and have a permanent record of what we wrote. Medium can be great. But if we want to write content that we keep coming back to, content that keeps evolving, content that’s part of a long-term project … and if we don’t want that long-term project to be locked into a single platform … then Medium may be a problem.
I say as I write this post on Medium.
Because I just can’t resist this editor.
Time to go add some code to Peasy so I can get it ready for prime-time sooner.
Featured image by paul bica (CC BY).
A prescient article written last fall before the news that Medium was downsizing significantly this week.