Coherence and connection
Let’s compare Perspectives to blockchain. We’ll start by asking ourselves: what kind of applications are built on blockchain? Famously, the first example constituted a currency. Later applications include ‘smart contracts’, energy sharing, and many others that all share the common characteristic that they support multiple interacting participants. One doesn’t, say, run a word processor or astronomic calculation on a blockchain. On closer examination, not any set of interactions will do: there must be some pattern, the interactions must constitute some coherent process (in contrast, an application like WhatsApp supports, superficially, random interactions between all participants. Of course the interactions aren’t random from the perspective of the end users, but they are as far as the engineers of WhatsApp are concerned). A further characteristic is that the participants typically are not (physically) close, like people in a room are; there is distance between them that needs be covered. In other words, they have a need to connect.
When we need to connect with people that are not nearby we apply technology like mail, the telephone or the telegraph. Nowadays we mostly rely on the infrastructure provided by the internet: a system that connects individual computers over arbitrary distances. For our purposes the internet consists of client computers, used by individuals, server computers, accessed by many and routers that chain them together.
Almost all programs that provide an information infrastructure to support co-operation, rely on a database. A database is instrumental to the coherence of the supported process. The information structures stored in it typically reflect the patterns of co-operation. For example: in a database supporting some commercial process we are likely to find orders, product descriptions and transactions.
However, the database also plays a vital role when it comes to connection. Instead of direct connections between participants, the database sits in the centre, both receiving data from participants and serving it to them. A buyer and seller, for example, interact by creating orders and transactions in the database. In other words, a database solves the problem posed by n interacting participants: instead of n*(n-1) connections, the system just needs n. Unsurprisingly, the database must reside on a server computer, while the clients access the information in it (mediated by the routers).
The takeaway is that both coherence and connection are served by the same vital component: the database, and that it is tied to a server computer.
Blockchain changes this picture insofar that it allows anyone to duplicate the database (usually to run it on another server, too). Instead of relying on a single centre — the server with the database — we now have multiple centres. Clients are allowed to access any server/database combination when they want to participate in the supported process; the databases somehow synchronise. This is entirely in line with the original vision for the internet. The military wanted an infrastructure to support their command structure that would not be vulnerable to attacks on a single point. While blockchain adepts usually have no military concerns, they argue that because anyone can duplicate a running database, no one party can leverage access control to it and that this is a good thing.
In the light of our discussion above, blockchain makes a difference on the level of connection. However, it also brings something to the table when it comes to coherence and that is the notion of transaction. Processes are conceived of in terms of transactions and much is made of the non-repudiability of the data describing these transactions, once stored in the blockchain database. Transactions are important in human interactions, but we strongly doubt whether any interaction can be conceived of as a transaction. We’ve written more about this in this series of columns.
Perspectives, too, is about information infrastructures to support co-operation. But we have an entirely different take on coherence and connection. The Perspectives Language (PL) has been purposefully designed to model co-operation. It allows one to describe the coherence of a process in terms of contexts, (user) roles in them and their perspectives, and, finally, properties of roles. All this is completely separated from connection. The importance of this cannot be overstated. It means, for example, that the notions of ‘data’, ‘message’, and ‘storage’ are entirely absent from the language.
So how is connection being addressed?
Users run a program called the Perspectives Distributed Runtime (PDR) on their computers. A process is initiated by a user creating a context, taking a role in it and inviting others to particular other roles. Her PDR then works out from the model governing the coherence of the intended process, what information should be available to these other users. This is a process of logical inference that we call model reflection. In short, for each participant, a tailor made version of the data describing the context and its roles is created. Subsequently, these packages of data are sent automatically to the other participants, using a message broker (a message broker service is like email for computer programs). The receiving PDRs authenticate and authorise the information, re-build from scratch the context originally created by the initiator and store it locally on the receivers’ computer. Notice that the message broker is not part of Perspectives; it is an independent service offered by many parties, just like email providers do.
In short, each user keeps his own stuff. When someone makes a mutation, a series of deltas is sent to the concerned parties, according to the model.
To sum up: in Perspectives, coherence is described without reference to connection; this is catered for automatically by the PDR using logical model reflection and a message broker service.
The glaring difference with database-dependent programs (including blockchain) is that there is no database to take care of connection. Databases do play a role in the PDR stack, however: client computers keep their data in local databases. But connection is driven by the logical model of coherence and executed by the broker service, deep down in the program stack.
This approach has multiple advantages.
Confidentiality is realised to the max, in the sense that data is guaranteed to be only available on the end devices of participants who have been modelled (‘authorised’) to need it.
Integrity is locally ensured. An incoming delta is first authenticated using cryptographic signing (is the sender whom he portends to be?) and then authorised using the model (does the sender play a role that allows her to make the modification?).
Availability is ensured because each user keeps the data she needs on her own computer. Ordinary redundancy measures (such as backups) can supplement that and we also support storage in remote locations (let’s say, a cloud service) for parts or all of one’s data.
Vulnerability is reduced to the point that it is only possible to take out individual clients of the infrastructure support. To completely disable a process, all participants have to be hit, or the broker process has to be disabled. Notice that this does not disable clients; they can continue to modify data, and once connection is restored, deltas will be exchanged (conflict resolution might be needed, then). Moreover, the fact that each user keeps his own perspective on the shared contexts implies a huge redundancy, again making the information infrastructure highly resilient.
Access to functionality — a primary concern to blockchain advocates — is absolutely unrestricted. Anyone can download a model and initiate a process — one does not even need a server infrastructure to run it (other than a broker service, but access to that is in no way tied to functionality).
Non-repudiation is guaranteed in the most natural of ways. Each user keeps her own set of information, including the original deltas. Each delta is cryptographically signed by its author — and so is undeniable. This is not unlike how we used to ensure non-repudiation in the pre-internet age: with signed copies of contracts.
There is yet another point to be made. A database typically stores the information pertaining to many instances of the same co-operation process. Each instance may involve an entirely unique set of people, like, for example, in the case of AirBnB. Each rental case involves a (usually) unique combination of someone with a facility to let and someone with a desire to hire. These cases have little to do with each other (except for the fact that the same person may occur in multiple cases), yet they are all stored together. Why are they stored together? Because of the strong tie between coherence and connection that is inherent in the notion of a database. We cannot separate the two. In Perspectives, we can and do. The coherence is described by the model. This is a common conceptual factor in all rental cases, but physically it takes the form of a copy of that model on the computers of the participants. The connection is taken care of by model reflection and the message broker. There is no need to store similar cases together, on the same server in the internet.
This solves, or rather prevents, a large class of problems very common in todays’ internet-based information infrastructures. Databases are honeypots with desirable and valuable information. They motivate great ingenuity on the part of malafide parties, much to our detriment. Information infrastructure support structures based on Perspectives simply don’t have that problem. There is not much gain in hacking just my house rental activities — it only becomes interesting when it’s about millions of us.
This is the thirteenth column in a series. The previous one was: Helgoland. Here is the series introduction.