tl;dr A theoretical framework for dis-aggregating the web services stack and separating front end apps from back-end servers (databases, files, permissioning). (Part of a series of posts.)
The current web services paradigm relies on a vertically integrated and proprietary set of interfaces and technologies (even if it leverages open source components.) For example, when you access facebook.com, facebook’s servers send you some files with largely proprietary protocols that define the interactions of the web page and communicate your data back to facebook. Naturally, facebook doesn’t want third parties to take over its core functionality, nor to freely communicate with its servers (except via well-defined third-party Interfaces which can be turned off or changed at its own discretion.) In return companies like facebook assume the security and scalability of their backend infrastructure - they store your data on their own servers and use their own proprietary software to analyse the data as they please, both to improve their services to you, and also to monetise your interactions with advertisements.
The personal server paradigm I am suggesting would dis-integrate (or unbundle) this vertically integrated stack. Instead of accessing, say, a note taking app on Evernote’s servers, Evernote would create an app which you could download and install on your own personal server, much like you could download and install an app on your own computer or on your phone. However, the app would store your notes, not on Evernote’s servers, but on your personal server.
Such an unbundling of web services has a number of advantages, the most fundamental of which is the degrees of freedom it creates by separating the user interface (or app) from the storage of data. For example, under such a schema, you are free to delete your data or turn off your server so no one can access it. More interestingly, you could also delete your note taking app, without deleting your data (i.e. your notes); or you could install a new note taking app, which was created by another developer with a better interface, and grant the new app permission to access your old notes. Or you can even install an independent app that has access to your notes and analyses your note-taking habits. (I will discuss these data freedoms in more detail in a later post.)
Another advantage of disaggregation is that it removes barriers to entry, and allows more actors to compete more easily to provide better apps. Today, all app and web site developers have to grapple with data and web-site security, which they have to provide to their users. But it is hard to be both a security expert, as well as great app developer. And at the least, it takes quite some resources to manage security effectively. It is no wonder that all but the largest companies seem to experience data breaches. In a disaggregated stack, a developer that focuses on a front-end app need not worry about managing users and their security, nor to safeguard its users’ data. In this model, the security is dealt with by another layer in the chain, so it is easier and less expensive for diverse app developers to introduce new apps (especially since incumbent apps don’t have a lock on your data.) App developers can specialize on their area of expertise, unencumbered by adjacent horizontal layers of the value chain. And they can compete to provide the best service to us!
Of course, anytime you slice through a vertically integrated stack to create autonomous horizontal units, you give up (at least initially) on some of the advantages that integration brings. Experienced developers will probably shiver at the thought of not controlling back-end functionalities of an app. However, precedence shows that creating simplicity, defining common interfaces between stack elements, and removing barriers to app-creation can also unleash much creativity and generate value propositions where none existed before.