The Personal API.
It’s a really interesting idea – to have your own way of interacting with online systems. Most big online systems today utilise APIs (or Application Programming Interface) in order to transfer and transact information. APIs have been around for a long time, but they’ve mostly been internal and accessible only by developers. That’s changed dramatically over the last few years as more and more technologies provide public APIs that allow you to exchange information, access services, publish information and what powers the ubiquitous “Share” functionality from you desktop to your phone.
But what if you had your own?
What if you were able to interface directly with the variety of systems out there in order to build your own products, services and applications?
What kinds of systems would you be able to build? What would they look like? How would they even work?
What follows are some initial thoughts of my own. I’m putting them out there as a kind of provocation, a conversation starter. I’ve written them to be considered on their own, each with it’s own merits and flaws. Let me know what you think too – maybe we can actually resurrect some old time blogging to respond to each other 🙂
The ultimate aim of the Personal API is to claim sovereignty over our own identity. It will allows us as individuals to define ourselves, manage how we are presented and more importantly control how we interact and transact on the web. The Personal API provides a method and a mechanism for us as individuals to reclaim choice and turn the web back into a participatory medium.
The Personal API is a first step towards independence. It represents a push towards a more democratic web. The only real threat to the oligarchs of Silicon Valley is true democracy. The Personal API has the potential to create the means towards something akin to universal suffrage on the web. To bring power back to the people. It’s more than reclamation, it’s liberation and provides the instrument to empower the Node, to take control and have autonomy over your digital self.
The Personal API is how we can create distributed systems. The problems we have with the web at the moment is that they have become too centralised instead of distributed. Centralised systems create a panopticon – and that’s the business model for companies like Facebook and Google. We get services for free but they get to constantly capture our data. One way to defeat this predatory surveillance system is through distribution. It’s a more complex process and way of working but in the broader sense it’s better. It’s hard work – to establish and agree to protocols, standards and to stick by them – but once you have them you’ve created a platform. A platform for individuals to create, innovate and invent. SMTP is a great example of protocol as a platform. Where the standard allowed you to use any service, any application, any client and email would still work. There is no autonomy in these centralised systems, they strip you of the ability to make choices. You don’t get to decide. You don’t get to choose the app, the client, the service – it’s all or nothing. It’s all in their eco-system, on their Terms (of Service). You can’t tweak the timeline. You can’t choose stars instead of hearts. You have no choice because you’re not a participant. You can’t reach out beyond the eco-system. You don’t exist outside the eco-system. A real social network would allow you to socialised with those outside the network, not force them to be part of it. A Personal API can provide the glue to make those connections. To bring people together on their own terms. To create our own civic space through which we can socialise, connect and interact. No longer confined to their space, we can have OUR space.
The Personal API provides the system for choice. It provides a way to PUSH information out into the world and to choose how you’re connected. But it also allows you to decide how information and interactions could be PULLed back. That it’s not just about the act of publishing, there’s the possibility of hospitality. That you can welcome someone in to access you data. That it’s not just about feeding their database, filling in their forms to create an “asset” – instead you can welcome them into your world. What if we started to participate in these transaction? If instead of filling in another form with exactly the same information again, what if we had a handshake – an exchange of data that is mutually agreed to and one that is built on the premise of hospitality, not authority.
As a complete aside I just wanted to include this rant about forms. If there’s one thing that the Personal API should make redundant it f$@!king online forms.
Filling in forms is not participatory – it’s a demand and the inconvenience is on me.
Even if I’m attempting to give you money, the onus is on me to provide you with information.
It’s all one sided. The exchange is unfair. Not only do I give you money but you get to store my private information.
And that private information gets stored in way where you choose the method of security.
Your business is improved and made more efficient, but what’s in it for me?
That’s not an exchange.
The Personal API provides a way for transactional behaviours to become much simpler. You don’t need to store my information in perpetuity if I give you access to it. You just need it long enough to complete the transaction. You could keep a “memory” of me, but there’s no longer a requirement to keep all my data forever. As a user I should also have some control over what this “memory” looks like and how long it stays. As participants we should be able to define when and how data is forgotten. As participants the lifetime of the data should reflect the nature of a transaction. If it was a one off, then the data retained should be that, not coopted and personal information stored in yet another database. Through a handshake process we can agree to terms – what data can be accessed, how often, how long it an be stored and under what circumstances.
A Personal API would allow us to assign a death to data, a point in which it is forgotten. If instead of data being stored in a database, it was simply accessed from ours then we can create a termination point. Once we have completed our transaction we can go our seperate ways. I can turn off the tap instead of being tied to your database for eternity. In doing this we can create attached value for our data, that it’s not something we just give up for free but is a kind of currency. If we can control the flow of data it can become scarce, rather than something that is scooped up as par for the course, because the reality is most businesses don’t need to retain our information. They do so because they themselves are limited. What if instead of storing personal data they simply accessed it via a key, a key set by the Personal API and which you can control. Then you could actually have real data protection. You could have real private services and actual privacy going into the future.
The Personal API provides the backend for creating of my own operating system. This backend that’s powered by the web would work as the equivalent of a device operating system, but one that I can integrate into multiple devices via a set of applications. That regardless of the device, operating system or hardware I can connect all these things to My Operating System (MYOS). That instead of service Cloud being the duct tape between applications, that MYOS is the sovereign source and all data goes through it. That I can allow applications can access this layer – I don’t need to set up multiple accounts or profiles and authenticate through them – they authenticate with me.
The Personal API provides an opportunity to fix the problems of the web. It creates a new way to think about the kinds of systems we need, how they’re designed, what they look like, how their maintained and by who. It provides a tool to reshape the web. You could re-create the services we love as infrastructure, as a utility that we can all access and share without the corporate interests. We can customise these services to suit us. We’d get to choose! It could be as simple as choosing if we want Hearts or Stars or Poop emoticons. What if “tweeting” was a protocol rather than a business? We would not be beholden to venture capitals choices as they drive to monetise.
The Personal API provides a mechanism for us to make decisions about the web as individuals, as friends, as communities, as institutions and as organisations. That the Web can be something that we do together, not something that is done to us. That the web that we’ve seen transformed from the individual spaces into the contained controlled and surveilled, can become a social and civic centre.
The Personal API is foundational to the next web, and what I think the next web looks like is a return to the distributed network. It’s Web 1.1. Same ideals and goals as before but with a decade or more of technological change behind it and a slew of lessons learnt from the foray into Web 2.0 and centralisation. Why is the Personal API foundational? Because what we should have learnt from Web2.0 is that the web doesn’t handle our identity. It creates space to express it. Databases to store versions it. Bots to define and track it and Corporations to monetise it to service ads. The web doesn’t provide us with a way to create, define and manage our own identity. Instead we’ve offloaded that responsibility to Google, Facebook and Twitter. We’re generously able to have a single sign on across the web, just with an identity ultimately controlled by someone else.
The Personal API needs to be accessible. We need to take lessons from the UI and UX world in particular the Facebooks and Instagrams. That if we’re planning to change paradigms then we have to bring people with us. If that requires a staged approach then we do it. If it requires analogies and skeuomorphic flourishes to begin with, then do it. If it’s simplicity over features then do it. It needs to make people feel it belongs to them. It might start off replicating or replacing existing paradigms to set itself in motion and once it reaches a level of maturity take off the training wheels. Not everyone wants to run their own server or open up terminal. Some just want a human at the other end to take care of it. The Personal API should be a seen as a service rather than a technology.
PS – I have to acknowledge the posts from Phil Windley who have really clarified some of the thinking on this – in particular the concept of sovereign identity and the awesomeness of SMTP.
4 replies on “Provocations on the Personal API”
timklapdor.wordpress.com: mentioned this in Provocations on the Personal A…. via kinlane.withknown.com
[…] initial musing about the Personal API (P-API) are in this provocation and boil down […]
[…] https://timklapdor.wordpress.com/2016/03/01/provocations-on-the-personal-api/ ↩ […]
[…] Mathers, Rob Farrow and Brian Lamb. They picked up on some thoughts about the Personal API that Tim Klapdor summarizes really well here, some ideas about the Next Generation Digital Learning Environment and concepts of data and […]