Web 3.0 and API 2.0

APIs which allow direct communication between applications have become more and more common as interoperability between applications becomes more important. In the future we may also reach a point where API will not be used only by applications but also potentially by people, of course not directly but thru some UI which will allow everyone to personalize their customer experience 100%.

This however is not really what API 2.0 should be, as it will mostly be a cosmetic change, a way to fully customize UI.

The assumption behind the idea of API is that API is an extension of the application to allow a more flexible use of the application.

However in the context of a decentralized Internet the idea of API can be pushed much more far.

It’s possible to basically turn the whole thing on its head making the API the core component of the application and the application itself simply an extension of that.

With the introduction of the Internet, computers (I’m referring to client computers and not servers) have transitioned from machines designed for storage of structured data to machines used mostly for communication. The communication part has become the core element of the user experience whereas applications like storing address books, documents, pictures now completely rotate around the communication aspect.

Since communication has become so important and the application itself is now nothing more but a preferred way to browse the communication the main priority should be allowing that communication to run as smoothly as possible.

As the communication becomes more important its structure becomes more and more rigid and standardized whereas the application becomes more and more flexible in the way it presents the information to the user. Once you have information as your most important element you actually want your protocol to be as rigidly defined as possible so that any possible application can interact with it. It becomes a world where the applications may change and have a lifecycle for example when they die out to competition but the protocol should not change as it should allow for this evolution and competition of applications. This is a completely different framework than what we are using now where the applications define the protocol and the API is based on on the needs and the structure of the application itself.

The idea of API 2.0 is an idea of “API First”. That is 1st the protocol must be defined and then the applications should be designed and compete with each other.

Of course this requires the use of a block chain as a central point of exchange for all those applications using the same API. There is however an issue with that which is the problem of competing implementations in the world of block chain. As we have seen already running competing implementations creates a significant risk of hard forks (potentially even just because of a bug) which could lead to a split of the network.

In this explanation we are not trying to use block chain for the sake of using block chain (something that has become very popular). If you want multiple applications to communicate through API in a model where the protocol comes 1st and the application 2nd you certainly cannot have applications directly communicate with each other as this will lead to specific applications becoming hubs and be able to modify the protocol based on their agenda.

Something similar has happened previously in the world of web browsers. Some browsers have implemented things in specific ways instead of others and the market share of the browser is going to determine which changes are going to be adopted and which ones are going to be discarded. This of course is not the ideal way to define standards or protocols as it concentrates and centralizes the decision power in the hands of a few agents.

The block chain is then needed as the central place for exchange of information just like for example in the financial world some stock will be traded on the NASDAQ which would be the place of reference where the trade happens regardless of how the trader is going to experience the operation (through his broker over the phone, with some application, on some webpage, with some script using an API, etc.). In that world there is no way some broker can make changes to the protocol just because he wishes so. The NASDAQ is the official exchange where every trade has to happen. In that sense for the API 2.0 idea you want something similar but of course decentralized which will be then be based on block chain.

Since because of competing implementations you cannot trust the players to simply create and maintain their own block chain because of the risk of hard forks you need some solution that will allow to build a decentralized block chain that should run on a decentralized framework.

This is basically what the Polkadot project is trying to do: Create a decentralized bedrock on which block chains can be built and maintained without trusting that the clients that are going to access this block chain should be able to ensure the integrity of that block chain (from a consensus mechanism point of view but also to mitigate the risk of heart forks derived from small differences or bugs in competing client implementations)

All applications which are communication centric (most of them nowadays) will then be able to “settle” their communications on the block chain and interact with each other through the block chain.