Michiel de Jong has worked as a programmer, researcher and sysadmin in Amsterdam, Oxford, London and Madrid, where he ended up as a scalability engineer for Spain’s national social network Tuenti. In Winter 2010 he took a two-month hacker’s holiday in Bali to set up the Unhosted project. He now lives in Berlin, with Kenny Bentley and Javier Diaz, where they plan, donations permitting, to work on the project full-time.

Chris Woolfrey: Would you like to explain the Unhosted project in your own words?

Michiel de Jong: There are several ways you could explain it; my favourite angle is the software freedom angle. Software freedom used to mean the right to control (use, share, study and improve) the source code / the program that the application executes – the definition that FSFE uses. Back in the day, that was enough. It was taken for granted that you already had control over the data that the application handled; of course you do, it’s on your computer, or on a server where you have full access to at least the data that your applications are using.

For installed software, both desktop and server, that view used to be accurate: if you controlled the source code you had software freedom. But then, slowly, installed software was pushed further away from the user by hosted software (stuff like Google Docs, Facebook and Twitter). Hosted websites like these aren’t primarily a source of information; they are interactive applications, and in this context software freedom doesn’t exist.

It’s absurd that hosted software makes you surrender your data to the author of the application in question, but it’s what happens. It happened slowly, because informational websites became dynamic websites, and those dynamic websites then started accepting user input and slowly became interactive software. Now fully hosted software is widely used, and people use it to replace locally installed desktop applications.

“Software freedom requires code-freedom plus data-freedom”

In the shift from local applications to hosted applications software freedom got left behind. Nobody talks about locally installed software any more, they talk about hosted software, yet some people say “I run an entirely Free Software stack on my laptop; only the firmware of the graphics card is proprietary”, and that’s a mistake, because so much of the ‘software’ that they use is not installed locally on their laptop, it is merely viewed through their web browser.

The Unhosted project aims to invent and promote a way to fix these issues. Software freedom nowadays needs to be not only code-freedom; it must be code-freedom plus data-freedom.

CW: How does Unhosted achieve this?

MdJ: We’re separating the code of an application from its data. When you log in to an Unhosted web application, the URI in the address bar determines where the code lives, but the domain succeeding the ‘@’ symbol in your username determines where your data lives; this frees your data from the hands of the application server, and frees the application server from the burden of your data.

This means that free of charge hosted Free Software web applications become feasible again. After all, there is an obvious Free Software replacement for Microsoft Windows: GNU/Linux, just as an obvious Free replacement for Microsoft Office is Libre Office. But what Free Software can so obviously replace Google Docs? Why can’t you go to ‘www.libredocs.org’ and use Free Software on the web, just like you can with desktop software?

The simple answer is that the costs of running software remotely on a server and providing it as a service are too high to be able to provide it free of charge. In order to write Free Software, all that is required is the time and skills of the developers concerned. But there is no way to make Free Software available to the world online which doesn’t involve a monetary cost, because doing so requires the use of servers, and whoever owns those servers will charge you a monthly fee. Our architecture for separating code and data, leaving the processing in the browser, fixes that: it makes it very cheap to host Free Software web applications because all you have to host is the application logic, the code files, not the data that drives it.

“Unhosted makes it very cheap to host Free Software web applications”

That’s the ‘free the application from the burden of your data’ part. And then there’s the other part: that software equals code plus data, but software freedom equals code-freedom plus data-freedom. With Unhosted, data-freedom is achieved because when you sign in to some application you decide which domain gets to host your data for you. You can get an account with a public provider – they’re in the process of being set up – or tell your university or employer’s sysadmin to run a node for the faculty or for the office, then basically everybody who has an email address ‘@wherever’ would get an Unhosted account with that same user name.

CW: Are there privacy benefits of using Unhosted applications when compared to traditional web applications which store both code and data remotely?

MdJ: When using an Unhosted application, all your data is encrypted by your web browser before it is sent to the server where your Unhosted account resides. That way the data stored in your Unhosted account can exist on any commodity server, because although you rely on that server to give you access to your data, the data itself is securely stored and encrypted, and you need not worry about your Unhosted account host reading your messages, for example. The data stored by an Unhosted application is encrypted by your web browser before it is sent and stored in your Unhosted account, and it then gets decrypted when it is sent back to your web browser when it is required. The server storing your Unhosted web application data is blind therefore; it sends your data to and from Unhosted websites without being able to read its contents.

Normally, using JavaScript for cryptography doesn’t make a lot of sense because if a website includes JavaScript scripts for encrypting data then those same scripts could be used to eavesdrop on the encrypted data. But in these cases the cryptography scripts originate from the same untrusted source that the encrypted data would then be sent to and received from. In the case of Unhosted it’s different since we separate the domain that delivers the application code from the domain where the data is stored. The Unhosted account provider will not have access to the application’s JavaScript cryptography scripts, so the Unhosted web application can encrypt things that the Unhosted account provider won’t be able to decrypt.

CW: What kind of applications do you think are best suited to using Unhosted? What types of web application do you expect to adopt Unhosted first?

MdJ: Any application which doesn’t store a large amount of user data can be easily adapted to use Unhosted. Applications like Google Docs which require the storage of a lot of important user data would benefit most from moving to Unhosted however. For parallel computing it will also be a great boost. But for other things, like search engines, it would require some clever algorithms to allow it to work in a more decentralized way. In general, any web application that requires the storage of a large amount of user-specific data could benefit from becoming Unhosted.

CW: It sounds like there’s a lot of scope for Unhosted to have a big impact on other web-based Free Software projects; how does your work fit in with things like Diaspora, Appleseed, and YaCy?

MdJ: Unhosted was sort of born on the Diaspora developer’s mailing-list. We were talking about how Diaspora switched from PGP to SSL, and how end-to-end encryption would be nicer, so I started trying to write Ajax payload encryption. It was meant to be an addition to Diaspora. Later I realised that it could be used much more widely than just for Diaspora.

We have yet to start to write an Unhosted social application that could federate with Diaspora and Appleseed instances. Because YaCy is a search engine, it would require some engineering in order to combine it with the Unhosted Web application architecture.

“I realised that it could be used much more widely than just for Diaspora”

Apart from the ones you mentioned, we were approached by LibreOffice to talk about how Unhosted and LibreOffice could work together. That was a great honour. We are currently implementing an Unhosted cloud-sync for LibreOffice. It doesn’t bring LibreOffice to the web in the sense that it would put the whole of the program into your browser, but it makes LibreOffice into a ‘document browser’ similar to a ‘web browser’, and it will be compatible with the web standard we published three weeks ago.

Other than that, we are only just getting started. We’ve put out a demo application that shows you how to do it: myfavouritesandwich.org. People can copy that and use it as a ‘Hello World’ starting point on the Unhosted web.

CW: What a great domain name!

MdJ: It was originally myfavouritecar.org but Javier thought that myfavouritesandwich.org was funnier.

CW: Is the way the project looks important to you?

MdJ: 33% of our full-time team is a graphic designer. That’s another pretty unique fact about this project; I don’t think a lot of Free Software projects reach that percentage. We need end-users to switch, and end-users often don’t understand software freedom, but if we make really nice applications, they’ll come for the applications, and stay for the freedom.

There is no threshold for the end-user: that’s an important feature for us. The user doesn’t need to know whether an application is hosted or Unhosted; if the Unhosted-ness is invisible then we’ve done a good job. We need to convince web developers to develop Unhosted web applications, and their clients don’t even need to know exactly what it is. If a client asks the developer for something new then the developer just needs to be able to say ‘OK, we’ll use the latest technology to develop that web application for you’, and then develop it as an Unhosted web application. The client need not notice that you used Unhosted’s architecture, only the web developer needs to know.

We want to create a few demo applications that are really nice to use, so that we can avoid the usual stigma that Free Software often gets from non-converts; that a program must be ugly if it’s Free Software. I think it’s important that Free Software looks nice and feels nice. A lot of projects are doing a really good job now, and we want to be one of those: that’s why 33% of our full-time team is graphic design.

CW: It seems that you’re trying to appeal strongly to people outside of the existing Free Software ecosystem. Do you think that there are obvious benefits of using Unhosted for non-Free Software companies and organisations?

“Users will come for the applications, and stay for the freedom”

MdJ: Yes, definitely. First of all, a company that uses software as a production means may want to use the end-to-end encryption so that company secrets don’t leave the company virtual private network, but still use storage on Amazon servers, for example. So they could use Unhosted web applications with Unhosted accounts that store encrypted data on Amazon’s servers, and it would all work from their staff’s web browsers without having to install software on-site. Also, the scalability and robustness that comes from a distributed architecture can make good business sense: if you want to offer a proprietary application, but don’t want your servers to be a single point of failure, then the Unhosted web will give your application less downtime, or at least incidents will be per-user, and your application will not go down entirely because of localized problems. Also, the cost of hosting an Unhosted web application is much lower than the cost of hosting a traditional web application.

That’s a great advantage for public domain projects that, at the moment, simply cannot afford to host web applications, but for proprietary applications it’s obviously also an interesting feature because it can cut costs. And then there is the potential business of setting up as an Unhosted account provider; depending on how many interesting applications we can get out there, companies like this will also pop up, so users will start using their brand as their login for all the unhosted websites that they use. The potential for interoperability between applications is also exciting – because you separate the application from the data it will also (where format compatibility allows) become possible to switch to a different website and see, for example, that all your photo albums are there, then switch back to the previous website and see your edits have come through instantly, without having to export or import, because it is the same data.

That will be a shocking experience for end-users when we get it working! Some people don’t care about scalability, robustness, encryption, privacy, public domain applications, software freedom, or any of that, they only care about this possibility of data interoperability. This kind of interoperability could be the best feature of the Unhosted project.

CW: Why has it taken until now for a project like Unhosted to arise?

MdJ: I think it is all very recent. One year ago, the landscape didn’t show as obviously that there was a problem as it does now: yes, there was Richard Stallman’s article about SaaS, then Eben Moglen’s seminal speeches, but in the meantime, Facebook became dominant. I mean, 18 months ago Facebook was still not as much of a monopoly as it was 12 months ago. Also, Chrome Web Store and Chrome OS were announced only quite recently.

Two years ago it wasn’t so clear to see. I mean, I know I couldn’t have thought of all of this two years ago, but I think the time is ripe now. But many of these ideas are not mine: some very important ideas came from Tim Berners-Lee and Zooko, and I just put them together and wrote a ‘manifesto‘ about it, which again, is mainly copied from Eben Moglen and Richard Stallman.

CW: How do you plan to devote yourself to Unhosted full-time?

MdJ: Next month we want to raise €36000. We had the choice of founding a business start-up or running the project entirely as a non-profit organisation. We chose the non-profit route because we think it’s important to do so. We’re three full-time engineers, and we’re intending on getting a hacker space in Berlin for the three of us, plus two spare desks for visiting hackers. That will be open for holiday makers who want to spend a week in Berlin, hang out in our hacker’s loft and contribute to freeing the web. Rent is very cheap here in Berlin, but we still each need about €1000 per month to live off.

We’re very passionate about this. In the near future we’ll be publishing tools and demo applications to push the Unhosted web forward, and we’ll work out the details as we go along. It’s a community project, entirely open, but I do think it’s good to have the ‘foundation plus community’ structure, with a small full-time team to give it some steady momentum.

We’d love people to subscribe to our mailing-list, follow us on Identi.ca and Twitter, and come to our IRC channel. Apart from that, we’re encouraging people to fork our demo application and build their own Unhosted application from it. The Unhosted web starts here.