This article was translated by Alexis Métaireau, on a train between Rennes and Paris.
While discussing about Kinto, we discovered that the future we envision for Kinto is the one of a collectively decentralized hosting, rather than having every user having their own individual servers.
Kinto wants to answer two basic needs from Web users: storage and sharing of data, without letting them losing control over their own data.
If Kinto should be a "database for the Web", then it is a pre-requesite that every user of the Web can easily access a server running it.
Deploying servers isn't something easy. A lot of people are working hard on solving this problem, but there is still a lot of work to do before having a plug and play solution that is easy to maintain over time.
Servers needs to be updated to avoid security issues and to be kept alive for the ones who needs them.
We can see it on our deployed software: we are very lucky to have "Ops" handling this. Believe us, if these tasks were easy to automate, they would already be! (Nobody wants to wake up in the middle of the night to solve other's problems)
Unfortunately, we are not yet at a stage where the state of the art allows everyone to self-host in a durable way.
A real work is needed to propose a service that works well for the users who needs it.
An answer to this problem seems to be a system with multiple centers: Decentralized.
Rather than having only one place where everything is stored, we could have one or multiple servers, handled by communities (EFF, The local linux user-group of your city, etc) which would help factorize the costs (both human-wise and money-wise) of maintaining these services. This allows to host one server for many users and applications.
I can see you from here, mumbling: "He is nice with his community-baked servers, but I don't want to give my personal data to anyone!". And you would be right.
Kinto allows to store any kind of data. It could be data meant to be shared or data that are yours and should remain private.
One of our goals is to help making encryption dead simple so that nobody (except you) can read your data.
Kinto.js actually handles this pretty well, as Michiel showed in a previous article..
Avoiding the creation of a new silo
In order to avoid participating in the creation of new silo, it is important to take care of a few things:
One of the mechanisms allowing current silos (Facebook, Twitter) to continue is their identity system. You want to share data with your cousin but you only have her "Facebook account" to connect with her.
For sure, this is a bad situation, but let's try to solve one problem at a time (unfortunately, Mozilla Persona, the decentralized identity service is End of Life).
Let's allow people to authenticate with their best-choice solution, being it open or not (OpenID, Firefox Accounts, Github, Twiter, Facebook, etc.) but let's give them back the choice of where their data is stored.
It should matter which storage solution you chose. It is crucial that interfaces exist to go from one to the other.
Kinto exposes (before all the rest) an HTTP API (some would say RESTful) which speaks JSON, which make it very easy to integrate with other solutions.
As a first step, it could only be import / export features from one solution to the other, but it is better to choose a format to be used for this data exchange. Without what a de-facto standard will emerge, for the best and worst.
We should start the collaboration with other "private cloud" providers, like OwnCloud or CozyCloud.
The latter started the creation of a working group on the matter, which wants to use MicroPub and WebMention as starting points.
The creation of community servers should not block the users to use their personnal server for the tech savvy.
In which case the community servers could serve as a backup, in case of a failure of the personnal servers (or in the other direction, the personal servers could backup community ones).
We can foresee a future where each user could have her own Kinto server, but we need to go there step by step, and prepare the field before being ready for a one click solution for Aunt Jeannine.
Having an easy start seem to be key here: start by using a community server and migrate later to a personnal server once all the technical problems (previously mentionned) have been solved.
In the meantime, an approach based on top of multiple communities seems to be a pragmatic solution in the short/mid term, bringing back some freedom to the users.