In this article, We discuss the approach we can take to solve the problem of discovery of Kinto servers.
How does an application discover the location of a Kinto server?
Any user can store data on Kinto servers. However, there has to be a way for the user to choose where the data are getting stored. The location of the server in the form of a URL can be shared with another user in order to collaborate and share data between multiple users on the same Kinto server.
To solve this problem, the following approach can be taken:
A] Let the user enter the location of its Kinto instance, the first time.
It is basically an user interface for how to specify the “remote server” to use. The user has to enter the location of the server only once, the first time he uses a Kinto instance, later on, this location will be discovered.
The best way to start doing this is to do it in a webpage that uses Kinto.js and let the user specify the server location. Once we have this, we will need to make this project re-usable by others.
B] Store this location remotely
Then, it would be good if we were able, for a given authenticated user, to automatically discover where is their kinto instance located. To do that we will need to find a solution to save this location somewhere when the user enters the location of the server for the first time and then, the information will be discovered.
We also need to keep in mind that a user may have multiple kinto instance with regards to the application he will be using. So, the discovery of Kinto will be cross application.
Once we’ve added a way to specify where the server is locally, we will need to store this information remotely. This is where the ideas of a central repository and of a Distributed Hash Table (DHT) come into play. Since a DHT is by far more complex than a central repository, we will start with the use of a central server.
B1] Central Repository:
The client will be extended to lookup the location of the server remotely once the user is connected. The flow would then look like this:
- Connect to your account (Github, Twitter, FxA) using OAuth.
- The client fetches the location of the Kinto server on a central Kinto collection using the user credentials.
- The Kinto.js collection is configured to use this remote.
pros of using a central repository:
- Its really easy to setup and implement. The application searches for the user’s server by looking up the central repository.
cons of using a central repository:
- The user needs to trust a 3rd party as the links to the information of the user is being stored in one place.
- There is a possibility of leak of information that someone is connected to a Kinto instance, and where this instance is.
B2] Distributed Hash Table (DHT)
Once we have this mechanism in place, we can expand it in order to rely on a DHT rather than on a central repositories. DHT is a distributed system that has a way of mapping similar to hash tables.
pros of using DHT:
- The user does not have to trust one server only. There are multiple servers that hold pieces of the data.
- It is possible to add your own server to the DHT.
cons of using DHT:
- It might be complex to deploy.
- Harder to implement and verify
- It might be an overkill solution.
- All the data in a DHT are public so we would necessarily need to encrypt the data there.
C] Eventually at the end we should expand this mechanism to other services locations, using Host-Meta.
In addition to discovering the location of the Kinto server, add the possibility to discover other services (such as the identity service provider for the remote instance (ie Firefox Accounts)) using Host-Meta. Host-Meta is a browser module that is used for looking up the metadata of a host. It is useful for discovery of services associated with the host.
And once we’re there, all the Kinto instances will be discoverable !