Provocations on the Personal API

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. 


Empowering the Node & Avoiding Enclosure

This is my presentation from the dLRN15 conference – Empowering the Node & Avoiding Enclosure. Below you can watch a audio of the talk + slides or just the slides below.

In this presentation I’ve really tried to highlight the perceived problem with current online technologies and practices, distilling it down to the concept of Enclosure. I introduce a bit of Marxist theory updated for the 21st century and discuss Wark’s concept of the Vectoralist class.

The second half is a vision – or outline of a vision – of how we can actually overcome these problems. Not by recreating or developing new systems, but by redesigning the underlying models. By moving to a more distributed model, one that harks back to the original conceptualisation of the web.

This is a passion project for me and I’m definitely keen to collaborate and discuss the concepts behind MYOS. If you’re interested feel free to comment or tweet to start a conversation.


Make Your Own Slogan: MYOS and the Networked Future

When I started this post it was only a week since I submitted an abstract for the dLRN15 Conference, but the it’s taken much longer to pull this post together than I originally thought. The title of the talk that I submitted was Empowering the Node & Avoiding Enclosure and in this post I want to begin the process of sketching out some of the core motivations and ideas I’ve been having in regards to the technology for living and working in a networked world.

This is has been a process of attempting to bring together some of the ideas I’ve been dwelling over for the last year and a half about what is happening online, particularly in the ed-tech space, and alternative ways that we could do things. The ideas are very much tied into notion of networks, in particular the concept of distributed systems. I put it down on my “year ahead” post back in January as a topic that I really wanted to explore this year, so when the call for papers, and the list of speakers/organisers came out – I figured this was as good a time as any.

In the meantime Jim Groom has published a couple of posts, one & two, that share similar ideas, particularly around the architectures around how to build alternatives. Yesterday Michael Felstein also put together this great post on the EDUCAUSE NGDLE and an API of One’s Own. Both share commonalities with what I’ve been thinking in particular around APIs and an “operating system” of sorts. It’s kind of why I decided to get this post out even though in some areas it’s still only half-baked.

So what’s the problem?

The big issue that I have with the current raft of technology is centralisation. Some of the big players are working desperately towards concentrating all your data, profiles, media and personal information into their own systems (see Facebook has officially declared it wants to own every single thing you do on the internet). Commercial social media tools have given life to the idea that networks are things that can be created, manipulated, bought and sold. However,

a network isn’t a thing, but an expression of individual nodes, how they interact with each other and the relationships they develop.
The Network & Me

These enterprises do not operate as networks, but as containers. They are an explicit attempt to seize and monetise our digital endeavour by controlling the vectors through which they flow. They are closed, controlled and centralised systems that are attempting to enclose the web, the notion of commons and the ability to connect and share. Yes it will be possible, but on their terms and in their space. As the importance for digital networks grows, the tools we currently rely on are undermining their ability to function. They are becoming a medium where networks do not grow and thrive, but silos in which they become stunted and curtailed by a simple binary choice – accept or decline.

Technologies in which digital networks can thrive don’t look like the tools available to us today, or those planned for tomorrow. Not the learning management system, Facebook, LinkedIn, Twitter or Medium.

So what’s the alternative?

I’ve been a huge fan of Jim Groom & Tim Owens’ work on developing up the literature and architecture for a Domain Of Ones Own. I think that idea – a space owned and controlled by the user – is paramount in this networked age. It forms a solid foundation from which to build networks in a distributed way, rather than the centralised silos that are currently available.

I’ve been eating up information relating to domain of ones own projects and the related technologies and concepts like Known, APIs, Docker & Containers, Federated Wiki, WordPress, JSON, GIT, node.js, Open Badges, xAPI, Blockchain – because to me they all work towards developing an idea of how a domain of ones own can be transformed into an operating system of ones own. An operating system that can drive us forward into the networked age by changing the current technological paradigm to one that seeks to empower the node rather than enclose them. “Nodeware” rather than explicit software or hardware.

This platform would aim to improve the ability for each individual to connect and share with others in truly negotiated and social ways. A platform that allows us to rethink the ways in which we learn and engage with digital networks – distributed, negotiated, social, interactive and sovereign.


The genesis of this was an attempt to rethink the Learning Management System in a distributed rather than a centralised way. I was over bemoaning what the LMS is and was and so took it upon myself to think through the what a viable alternative might actually look like. If we simply reinventing the LMS we’d end up with something like the Learning Management Operating System that Feldstein and co developed. The central idea I was working on however was to provide students, rather than the institution, a way of creating content, recording learning, developing a portfolio and managing their online identity. The challenging component of this was to think beyond the standard institutional IT infrastructure and beyond a better centralised system but one that was truly distributed system. Domain of Ones Own showed that there was a viable alternative, and coupled with concepts embedded in the indie web movement such as POSSE (Publish (on your) Own Site, Syndicate Elsewhere) and the growing momentum behind APIs ideas started to form around a way to manage, mind and make your own learning:


That image was from about a year ago – the kernel of an idea was there but not necessarily the means to take it forward.

Over the new year I participated in the first Federated Wiki Happening and the experience of not only using, but embracing, a federated, socially constructed, non-linear and cooperative environment was fantastic. It opened my eyes to what could be possible if we re-thought not on the applications but the underlying technologies we used too. I loved the open nature of the federated wiki, but what I fell in love with was the concept of being an “empowered node“. The system worked in a way that empowered the individual. It provided tools and methods to create an individual identity while at the same time allowing others to connect social and professionally.

Last year I also worked on our university Badges project, and have been thinking about the potential of xAPI to capture a more nuanced and broader spectrum of learning and so have been broadening my concept of what’s possible technically and culturally.

A fortnight ago we held a workshop on how as an institution we could support Learning Technology Innovation. One of the key areas I wanted to explore with the group was APIs. So in the process of planning and putting together a presentation for the event I’ve been engaged in that space too. Just follow Kin Lane and have a play with IFTTT and you will quickly understand the power and potential that APIs offer. (PS this video offers a neat explanation of what the hell APIs are).

Welcome to MYOS

MYOS is the name I’ve given to the concept of developing a personal and social software system that provides not only the tools and technology to empower the individual in the networked age but some guiding principles about how it should enable, enhance and empower the user.

The name came from a bit of a play around with various combinations of words to describe what it would encapsulate:

  • make your own stuff
  • mind your own stuff
  • manage your own stuff
  • my online self
  • my operating system

MYOS could simply be – Make Your Own Slogan 🙂

MYOS is very much the model the Jon Udell laid out as “hosted life bits” – a number of interconnected services that provide specific functionality, access and affordances across a variety of contexts. Each fits together in a way that allows data to be controlled, managed, connected, shared, published and syndicated. The idea isn’t new, Jon wrote about life bits in 2007, but I think the technology has finally caught up to the idea and it’s now possible to make this a reality in very practical way.

Technology Foundations

There are two key technical components to MYOS – Containers and APIs.

Containers are a relatively new phenomenon and arose as part of Docker. They allow individual applications and services to be packaged in a way that can be deployed on a single server. Apps can be written in any language and utilise a variety of databases because they are contained their own package. At the same time they can talk to each other – share common layers that allow for greater integration. Containers provide a way for a variety of “life bits” to be co-located and packaged in re-deployable ways.

APIs (Application Programming Interfaces) at their most basic level allow applications to to talk and interact with other applications. APIs are the vectors through which information travels between systems. For many years they were primarily used internally with large and complex systems, but they are now emerging into the public space. They provide you the ability to cross-post between twitter, facebook, google and instagram. They allow you to push files to and from Dropbox from a multitude of applications. APIs are increasingly accessible not just to developers but to users too. Services like IFTTT allow almost anyone the ability to harness APIs to create useful “recipes” that link their own data and interactions in ways that increase effectiveness and impact.

Founding Principles

On top of those technical foundations MYOS aims to embed a number of key principles common with the Indie Web movement and help define what the system aims to do – Empower the Node:

  1. You are in control
  2. Data is yours
  3. Connections are negotiated
  4. Enhance and enable diversity

You are in control

The focus of MYOS is to empower the individual rather than re-enforce the network. Empowered nodes provide a stronger and more resilient network that is able to not only cope but thrive on change. An empowered individual is not locked in or enclosed within a single system but is free to move between them.

Data is Yours

You should always be in control of your own data. You should be able to decide who and how that data is accessed, viewed and shared. Data sovereignty is now more important than ever as we see how state surveillance and commercial enterprise has transformed private data into a commodity that is bought, sold and exploited. MYOS should ensure that any data is ultimately controlled and managed by the individual.

Connections are negotiated

In a world that relies on the network we need to ensure that democratic values are not lost. Individual choice has increasingly been eroded by the binary – Accept or Decline. We need to move beyond the autocratic rules that have come to define much of our digital lives. Connections need to be negotiated and a key way of developing that is building in a handshake mechanism that ensures transparency but also encourages users to negotiate terms that suit them. This would include being able to decide what information is shared, how it is shared, what is hidden, what is private, what is relevant, what is preferred as well as negotiating a period of renewal. This handshake could include the development of “data lifetime” clause to ensure that data isn’t kept in perpetuity, but can be removed or forgotten without the deletion or removal of the user or service.

Enhance and enable diversity

Rather than enforce a monoculture, MYOS aims to promote diversity. While there is a need for a stable core, MYOS should promote a diverse eco-system of applications. From a technical level a containerised approach enables different application built with different languages, foundations and data structures.

Making it Work

For MYOS to work it hinges on a number of cultural concepts:

Owners not Consumers

I’ve written before about my notion that society is transitioning from passive consumerism to active ownership. The current model of networks is very much on built on consumerist conventions and why much of the potential inherent in the technology has devolved into manipulative and exploitative marketing. As an alternative Ownership requires a personal investment and active participation in order to receive a reward. An owner understand that there is always risk and a cost involved, but rather than be manipulated into supporting a venture, they wish to be informed. Value needs to be demonstrated and transparent.


In a cultural capacity openness is still a fairly new and one that is continues to challenge and disrupt existing cultural modes, model and practices. Many aspects of Western culture are built on practices that install and maintain rigid hierarchies of power and exploitation that are achieved by ensuring knowledge is limited through secrets, lies and division. openness destroys those notions and instead requires trust to be created, managed and maintained through transparency and a shared experience. Openness seeks alignment rather than consensus, cooperation rather than collaboration – which tends to turn all processes into a “consensus engine”. Openness encourages federation rather than centralisation, a key tenet of MYOS.


For MYOS to ever function it requires a community, but communities don’t just happen. They require encouragement and nurturing as well as a level of active participation and contribution. Rather than being an emergent outcome of a social environment they require the result of careful fostering and cultivation. Community is the outcome of contribution, not participation. MYOS needs to be something that works with people, not for or to, and lies in the process of reclamation and liberation.

Agnostic Appropriation

Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while.
– Steve Jobs

MYOS isn’t a new thing. It’s an attempt to draw a line that connects a number of concepts that relate to our digital lives and the way we are increasingly living and working in this connected space. Movements (like the IndieWeb) and software (like Known) already provide aspects of the kinds of functions I see MYOS fulfilling. MYOS is an attempt to create a map of a networked idea.


In developing up a set of features for MYOS I started thinking about the idea of “Nodeware”. A combination of software applications, hardware and device that don’t just provide a service to the user – they empower them. They provide a rich set of tools to create, manage and maintain their online selves. Names are purely illustrative, but below is a quick list of starting features:

Identity Management – profiles and memberships
Cards – identities and personas
Keys – authorised access
Records Management – quantified self
Sash – badge display
Qualifications – certification, diplomas & degree
Shelf – web and print publications
Gallery – photos and graphics collections
Cinema – video collections
Radio – audio collections
Portfolio – assembled artefacts
Notes – ideas, notes and fragments of thought
Scrapbook – collection of the curated and salvaged

Expanded not replaced

The idea I’ve been working from is not an attempt to go and reinvent or recreate existing applications and services but to expand their features and connect them together. Open source projects make a perfect candidate for this expansion – so rather than replace Known or WordPress they can be developed in ways that integrate it into MYOS. One way that this could work is by rethinking something like cPanel and turning it into an OS level application that provides an underlying data structure and tools to connect and deploy various application via their containers.

More to come…

I’ve felt a little rushed to put this post out, but I wanted to join in the conversation not sit outside it. I’ll admit to not having everything fleshed out, or even properly specced, it’s still very much about an alternative way of thinking, designing and working with systems online. There’s a couple of posts I can see already that need to be written,in particular what the LMS and other institutional systems might evolve into when students are using MYOS. Until then I’d love to hear your thoughts and ideas.

Featured Image: flickr photo by rrruuubbb shared under a Creative Commons (BY-NC-SA) license