‘Dear Computer’: A World Where Computers Email Each Other So You Don’t Need To

Your employees can communicate with your customers and suppliers just great. So why can't your computers do the same?

Imagine you're CTO of a firm with lots of business relationships - any firm, in other words. How many times have you ruminated on the problem of staying in sync with all those other parties?

You have an amazing way of communicating and sharing information with individuals in all the firms you work with; it's called email. Everybody has it, everybody uses it; it just works.

But when you try to communicate and share information with systems in the firms with which you work, it's a nightmare! If you're lucky, there's a domain-specific network you can use, usually controlled by a monopolist who you have to watch like a hawk. Maybe, if you are really lucky, some of your customers or suppliers provide API endpoints you can call. But more often than not, you're reliant on file passing and massively unsatisfactory ad-hoc methods.

Now there is, of course, one obvious solution. Why not just set up a centralised database that you all work from? It could work in principle. But who would run it? Imagine what power a company would have if they ran the database that controlled an entire market!

So that's a non-starter. We simply can't solve market-level problems with a centralised database. Instead, we have to figure out how to connect our existing systems, not introduce some all-seeing panopticon. We somehow need to link these existing systems, which are deployed in a decentralised fashion amongst all the firms in the industry, in much the same way that the people in these firms are linked by email.

Now there are several historical, social and commercial reasons why this is hard and why previous attempts have usually failed. But in this post, I want to look forward. In particular, we can study a small number of motivating examples to show there is a real problem to be solved and then think through how we might, finally, allow machines to 'email' each other, just as easily as humans can:

Importers, exporters, their shippers and their banks often need to exchange information to facilitate the flow of goods and the financing that goes with it. This has been a heavily paper-based environment for as long as anybody can remember. Centralised initiatives have tried to solve this in the past, but the introduction of a new intermediary or service provider has typically resulted in limited take-up: email works so well because there is no "CEO" of the email network and nobody has to pay a per-email fee to send messages. 

Similarly, reinsurance is also a very collaborative, communication-heavy market characterised by wheelbarrow-loads of paper. And, again, centralised initiatives from the past tried and failed to 'digitise' the market. The fear of new intermediaries certainly played a part in their failure, but so did the lack of universality of many approaches. There isn't a different email network for car manufacturers and TV repairers, right? So why should there be different communication networks for computers in different industries?

Sometimes the trick to solving a specialised problem in one industry is to use a common, generic technology that can be used by all industries.

Imagine you were tasked with designing a protocol that enabled computers in different companies to communicate with each other, loosely analogous to how email lets humans do it. What characteristics or capabilities would it need? What problems would it need to solve?

I think the key things are: identity, location, reliable secure messaging, shared business logic and workflow and integration.

Let's take them in turn:

Identity

You don't know anything about your counterparts' IT systems but you at least want to know you're actually talking to the right firm. So, there needs to be some way to address your messages to real-world identities rather than random strings.

Maybe we can build on the existing email naming scheme for this or maybe we need something different, but the solution needs to take into account the fact that computers are unbelievably stupid.

We get away with taking a lot of risks around identity in the regular email space because there are humans at each end of the connection who can be trained to figure out when they're not talking to whom they should be or to detect when something isn't quite right. For example, even if you know that Bill Gates's email address at Microsoft was billg@microsoft.com, most people would be rightly suspicious if they ever received an email from that address. But when you take humans out of the loop, what are you supposed to do? How is one of your computers supposed to know that? Even with emails we see a huge amount of fraud and error.

A stronger identity scheme is probably required. It's tempting to say the public key infrastructure that protects the Web could help here but given the value that could be transacted over such a global network we should probably be pretty picky about which Certificate Authorities we trust and in which contexts. And it goes without saying that there should be no commercial entity with the power to deny access to such a network; allocation of names should work akin to something like how ICANN manages the DNS system.

Location

We also need the ability to locate services operated by our peers. Given that nobody knows better than your peer what services they offer, what protocols they support and how to find them, the solution should probably support some sort of "Peer Information" – or 'PeerInfo' – object concept: some authenticated way for a participant on the network to 'assert' things about themselves - "here's what I offer; here's how to find me" - and the authentication of that data structure should be strongly tied to the identity layer above.

Asynchronous Secure Messaging

Now it gets interesting. One of the amazing things about email is its asynchronous nature. I can send an email to you without needing you to be online – or even needing your company's email server to be operating 24/7. It will eventually be delivered.

We need the same thing for machines, and we also need to make sure it is secure. If one of my machines is sending a message to one of yours, it needs to be encrypted under a key that only your organisation has access to. So, we need something like the old MQ systems of the 2000s, that linked together machines inside companies, but toughened up and secured so they can be deployed across the howling prairie of the internet.

Shared Business Logic and Workflow

Imagine we've achieved all of the above. What should happen when a machine in somebody else's firm receives a message from mine? With email, it's easy. Some human reads it and figures out what to do.

That's fine for email.

But humans are clever, and machines are stupid.

For 'email for machines', we're going to need to tell the computers what to do. And, if this is going to work without adult human supervision, we probably need a way to write business logic that encodes some sort of business process, for example, the process for agreeing an invoice or updating details on an insurance policy. This code will look a bit like an application and also a bit like a workflow… multiple firms would need to deploy code that can work with other firms' computers running similar code but for any given interaction each firm's role would probably be slightly different.

So, we need some sort of application that can be distributed between participants in a business process, that is easy to write and which both captures business logic but also process and workflow logic.

Integration

Finally, we need a way to connect these 'email for machine' systems back to the existing systems inside each firm. We need to be able to automatically integrate with these existing systems.

Good news… Email for machines exists today!

This combination of institutional-grade identity management; self-sovereign service advertisement; secure asynchronous messaging; shared business and flow logic; and integration capabilities is the essence of what you need to link applications in different firms together.

And the interesting thing is: it already exists. 

You might know it by its more common name: Enterprise Blockchain.

Those of us working on blockchains in business contexts don't always talk about it this way: but this is what's going on at the heart of many of the projects we're working on.

If I look at a lot of the places where enterprise blockchains being deployed, a key part of the value being added depends on their ability to provide a neutral, shared, non-exclusionary, reliable substrate for 'email' between machines.

After all, if you couldn't ensure the right firms received the right information at the right time and that they were going to process it in the way you expected, none of the transformational benefits I so often write about could possibly be achieved.

Some platforms take this further than others, of course. The platform I helped design, Corda, has a particular focus on fusing identity, routing, asynchronous secure messaging and common business logic between firms, but we're not alone. These things may not sound earth-shattering but maybe that's the point: none of us claim to be magicians; all of us in this space are just trying to do old fashioned engineering, focused on solving market-level problems.

Do all enterprise blockchains work the same way?

In time, I suspect they will. Indeed, there are efforts in the Ethereum community, for example, to add support for some of these concepts to the enterprise variants of the platform over time. Baseline is one example - it's pretty early days but there are lots of very similar concepts there to those I outlined above.

But that triggers an interesting question. Imagine we ended up with feature parity between Corda, Ethereum, Fabric and all the others. What would happen then?

I suspect we'd then see the ages-old "consensus conundrum" rear its ugly head again!

The "consensus conundrum" is that you need to think about how transactions are processed and confirmed on the networks to which you deploy your applications because "finality" is a slipperier topic than any of us would like.

For example, imagine you'd deployed an "email for machines" solution that utilised a permissionless underlying blockchain for its transaction processing, and you'd been using it during the recent convolutions in the market owing to the current health crisis. Would a multi-hour backlog have been acceptable?

We wouldn't accept multi-hour delays for emails between people, and nobody is going to accept it with email for machines.

So, as ever, focus on your requirements, and match the technology to the problem to be solved.

EAC Public Meeting 81617