Why is the API model traditionally built around a central entity node connected to many consumer nodes, rather than the other way around? Why is it possible for me to connect with various APIs from cloud services like Twilio and Dropbox but I can’t create an API for myself that allows companies to connect with me?
Instead of going to the cloud, why can’t the cloud come to me?
Put it this way. I watch Star Trek on both Hulu and Netflix. My episode history is out of sync on both platforms. Why is that? Because these are separate services with their own backends. There’s no way for them to talk to each other, and there isn’t because there’s only one point of intersection: me.
But what if I could store my own episode history in a personal API, which then Hulu & Netflix would talk to? Both would have permission to update my episode history, and both would have read access. I would give Netflix billing access to the banking endpoint of my API, and so they would enable additional access on their platform. They could push content to my API endpoint and it could be synced between all my devices, including my phone which would also have read access to my API.
Everything would remain “in the cloud,” but the cloud would be my own personal cloud. A mini-cloud, if you will.
There are several types of information that could be stored in a personal API:
- My personal contact information
- My correspondence
- My media
- My preferences: brands, things I read, movies I like
- My shopping history
- My payment information
- My medical history and prescriptions
Pretty much all the things I do online I could do with a personal API, but there would be a few advantages introduced by creating a new protocol:
- I would be able to control my own data. Companies/services would need to request access to my data on an individualized basis. I would only give data that would be needed for each service.
- Privacy becomes completely up to me. I would be able to control how access to my data is granted and revoked. My data is only in place accessible only through authentication to my API. I can revoke access tokens upon request.
- “Add-ons” to my API service could be enabled like encryption or new REST endpoints, that would allow me to evolve what my API is able to achieve.
- I could create direct P2P connections with fellow users of the Personal API protocol without having to connect through a third party server.
- The protocol could integrate with multiple devices, but the nature of these devices would need to change. For example, if I wanted to send a message to my brother, right now I send a text message to his phone which gets routed through AT&T’s cell phone towers (for example). But with a personal API, I would send a message to his API endpoint, and his devices would all pull from it. So it would be like iMessage, but an iMessage that would integrate with *everything* I interact with.
- On that note, the “internet of things” becomes much more possible. Instead of having to program all my devices, my devices would be adapted to me. When I buy a new product, it requests access to my API, and then can interact with other services that also have access to my API.
- It weakens the government data dragnet. Right now, one clandestine program by the NSA can tap into Facebook once, and have access to everyone’s data. With a distributed personal API, the government would need to focus its attention on just nefarious or dangerous individuals. The legal status of a personal API would be more akin to a lockbox in my house than a self-storage center that is analogous to the current cloud.
If a personal API protocol were to be created, that would only be the first and easiest step. Cloud services would need to play ball, adapting their account creation and sign in systems, not to mention data access and storage, to work off of my personal cloud rather than their common cloud.
Speaking of Facebook, everything I have listed above is something Facebook could create tomorrow (or Google or Apple), and they may even be considering doing so. They certainly have access to the data necessary to create the API. But they also have the problem of centrally storing that data, creating a single point of failure/weakness/whatever. A centrally stored backend does not meet the criteria of a truly personal API listed above. It needs to be distributed.
Again, it’s a specious concept, and I can’t be first person to think about it, but I would be interested in A) If anyone has fleshed out an idea like this a bit more or attempted to build it, B) Either way, if anyone would be interested in working on something like this with me.
Would love your input in the comments.