Decentralised Interfaces

Ironically, I think one of the biggest successes of decentralised technologies like Ethereum and IPFS will be to centralise API design across organisations.

Currently, when an organisation wants to expose its services as an API, it decides on a medium. Often, this is HTTP. If we’re lucky, an SDK in different programming languages is provided; if not, those need to be written, and maintained. If we want to use a different medium, such as gRPC or websockets, we’ll need to hope the API supports them.

Then comes the problem of authentication. Typically, we’ll need to register with the service, after which we obtain a secret key. I’ve seen different methods of authentication using that key: plaintext, md5 encrypted, base64 encoded, HMAC using nonces and timestamps and myriad custom rules. This can be a hurdle when setting things up.

Most importantly, the Application Programming Interface is designed by the organisation. The plus side is that the organisation can design it any way it likes. The downsides are that, even for the organisation, that involves design work. Worse, it often just means poor design, or design “on the go”. This results in arcane interfaces that are hard for users to work with.

Finally, even organisations that provide a similar service have widly different APIs. Think for example of all the payment APIs out there, or messaging APIs, or social media APIs.

What I think decentralised technologies will strongly encourage is opt-in standard interface implementations. Think of the following loose pseudocode for a payments API for instance (similar to ERC20 on Ethereum):

interface Payments {
  type Account {
    balance
    sort_code
    account_number
  }

  CreateAccount()
  GetAccount() -> Account
  GetTransactions()

  Transfer(from, to)
}

This interface defines common functionality that many users would want access to. Any organisation would then be able to implement this interface as it chooses. Authentication can be built-in (i.e. digital signatures on a blockchain) or defined separately in a similarly standardised manner. Organisations would still be able to implement whatever functionality they desire on top. Or if there was a sufficiently compelling use case, the interface could be extended in whatever way the underlying technology suppports (e.g. updating a smart contract on Ethereum).

Simply having an interface defined in one place doesn’t mean it’s well designed by default. But it certainly provides a ton of evolutionary pressure to avoid unecessary complexity.

Imagine a brave new world with standard interfaces for all sorts of services. For example, an API for ride-sharing, upon which many other services could be developped:

interface RideSharing {
  RequestRide(from, to, parameters)
  BidOnRide(price, parameters)

  GetRideStatus()
  CancelRide()
}

Or a messaging API:

interface Messaging {
  GetMessages()
  SendMessage(to)
  ...
}

Now imagine using multiple of these APIs together, to build an entirely new service. I could, for example, create an application that groups hyper-local transport together, with a combined ewallet, that bids in linearly increasing increments on ride requests in an area, after which text messages are sent to users regardless of whether they use email, Whatsapp, Signal, Telegram, Discord, Slack, or otherwise.

And these are just trivial examples. The possibilities are limitless. I can’t wait for decentralised technologies to start centralising interfaces.