---
# System prepended metadata

title: Making Data Portability go Mainstream
tags: [solid, data-portability, hope]

---

# Making Data Portability go Mainstream

Data Portability is a broad term. You can apply it to document formats, as in office file formats. In this way you specify the structure of the data, but not the meaning. Solid (solidproject.org) goes beyond just the structure and makes the meaning of data explicit, using RDF ontologies.

The problem is that each of these seperately seems insufficient to make the proverbial 'killer app'.

The promise of Solid is that your data won't be tied to a single application. You get data portability for free, _if_ you use the same ontology.

But there is another approach we could take that has proven successful in the past, and that is the SmallTalk approach.

What would happen if instead of static file formats, a document was instead a living running application. Each document having one or more API's you could query. One of these API's could support queries based on RDF Ontologies, perhaps using LDflex (https://solid.github.io/ldflex-playground/). But it might also have additional API's. And if you know the document type, you might find translation programs that connect to the document using a supported API and translate to a different API.

This approach is similar to things like CORBA and OLE, but both of these were limited and complex. But the clearest implementation of this, is the current web. The only problem is that there has been no standardization on API's. Well, there is also the problem of linkrot.

The simplest way to create a document that can be read by anyone, is to use web technologies. Just write it in HTML, add CSS and a bit of Javascript, and you can create any kind of user experience.

Such a document can already link or embed other documents, either through hyperlinks or through iframes. You can query live API's over the web, using javascripts fetch() function, if the API allows it through Cross Origin Resource Sharing (CORS). To query a static document, one that is only rendered client side, in the webbrowser, the document must allow that as well.

One solution that works with the current technology is to use an iframe to embed a document. This document must then have an API, written in Javascript (or web assembly). The iframe has a communication API called postMessage(). This allows you to send information to the embedded document, cross origin. The embedded document can send results back using events.

If we take this mechanism and create a basic standard around introspection /interrogation of documents, you could create an environment that kind of works like a SmallTalk 'world', but one that is not limited to you local computer.

The main problem here is linkrot. On average a link remains valid (working and containing the same or similar content) for about 100 days. That means that by embedding documents from around the web, the resulting combination is prone to break.

One way to fix this is to leverage IPFS (InterPlanetary File System). By publishing your documents on IPFS you make sure that the content and the URL are inescapably connected. If you link to such a document, you can pin it, and be sure that the linked content won't change or disappear.

In addition IPFS makes it simple to lower the overhead of application code in the document format. If your application code (and API) is the same for many different documents, which is expected, you can just publish that application code to IPFS and link it from the document.

This approach is actually viable. I've made a simple prototype document that contains / embeds other documents that communicate between them. It uses a very basic message bus, based on iframe's postMessage and event model. It doesn't use IPFS or Solid (RDF) yet, but there is no reason to expect difficulties implementing that.

You can check out this experiment here: https://github.com/poef/a-new-hope

So how will this help us get to a killer application for data portability?

I hope that by focusing on documents that interact across the web, and that are inextricably linked to their application code and API, we can create a creative environment that makes it both easy and simple to build complex documents and applications out of simple focused building blocks.

Imagine being able to create a live presentation, with chat and multiple video feeds, just by creating a new document and dragging existing documents into it and connecting them using well defined API's.

Instead of having to go to an online service that has all the features you need prebuilt in a silo, you can build your own online application on the fly.

I think that this is a goal that is more ambitious than just focusing on data portability. It also shows a way to a more connected and involved world where you don't need to be a programmer to build new creative applications, to make sense of the world of data that we live in.

###### tags: `hope` `data-portability` `solid`