This article is the second part of our interview with Matthew Schutte, Communications Director at Holochain, which covers their plans to build a “Commons engine” to help provide co-ops with the tools they need to communicate, coordinate and cooperate at scale.

In part two Matthew explains how Holochain enables “protocol” rather than “platform” cooperation,  by proving an “adaptable” framework which follows similar principles to the way we share language and culture – with huge benefits for collaboration. He goes on to define Distributed Public Key Infrastructure – the way in which Holochain approaches security – and how Holochain apps can be “bundled” and  customised to provide a user-centric experience.  Finally, he explains the timeline for Holochain and their concept for a “Protocol for Pluggable Protocols”.

Read part one of the interview, Holochain – the perfect framework for decentralised cooperation at scale, for the background and an explanation of how Holochain could enable the kind of open source operating system, like PLANET, which we hope to see come to fruition.

OSB: You mentioned that Holo is aiming to build a “Commons engine” – what can you tell us about that?

MS: We’ve previously talked about the fact that we’re launching two things: Holochain and Holo.

Holochain is a pattern for building peer-to-peer applications that don’t need a company in the middle. We’re giving it away to the world for free. It is a pattern, not a platform.

On the other hand, Holo is basically like Airbnb for web hosting.  If you have some spare computer storage and processing power on your laptop or desktop, for any of the holochain applications that you are participating in (running on your device) you can offer to serve webpages to visitors.  You set your own rate for that work and if your price and performance history is good enough for the developer (or the community) that is running that app to chose to rely on you as one of their hosts, Holo will send you web hosting work. When you do that work, the developer that you are doing it on behalf of will pay you in Holo fuel, a new asset-backed currency system that we designed.  Unlike most blockchain based crypto-currencies, Holo fuel is not token-based. Instead, Holo fuel is a mutual-credit currency – meaning that the supply can actually breathe. There are a few advantages to this design, but the big ones are that this currency design can handle huge volumes of transactions and can do so even if they worth less than a penny each. Today’s cryptocurrency designs can handle only tiny volumes of transactions (something like 10 per second for many of them) and are ridiculously expensive. The price of a single bitcoin transaction rose above $40 in January. Nobody is going to spend $40 to send someone a webhosting fee that amounts to a few pennies.

So basically, Holo fuel’s scale and efficiency is off the chart relative to other “currency” or accounting systems (technically, we think of it as a crypto-accounting system that is optimized for micro-transactions).  Mutual-credit currencies have been around for hundreds of years, but by using it in conjunction with Holochain we’ve unlocked some really interesting characteristics.

In addition, we’ve learned a bunch of lessons through our own fundraising process.  These are specific lessons around legal, banking, regulatory issues etc. The world is grappling with a change right now, and we’ve managed to get a bit of a feel for where all of that stands at present.

The goal with the Commons Engine is to help make use of this new economic engine (our mutual-credit crypto-accounting system) and our familiarity with the fundraising, banking and regulatory worlds to help a bunch of other communities bootstrap similar economy fostering engines into place. You can think of this as sharing our design with select communities that will apply it to their own context to help foster flows of resources among the participants in their community.

Because the design of our crypto-accounting architecture is an asset-backed one, it is dependent on there being assets that can back the currency. In our system, the asset backing the currency is web hosting capacity (and a demonstrated ability to deliver).  However, other communities might rely on this same architecture for instead fostering flows of electricity, or food, or elder-care or rideshares amongst peers.

The vision with the commons engine is to power a series of thriving commons based economies – picture things like peer-to-peer renewable electricity cooperatives, or ride sharing communities – by creating the technical infrastructure that enables contributions by participants to be recognized elsewhere within, and perhaps beyond, that community.

That ends up enabling flows of activity regardless of whether the community possesses traditional “money.”

In addition, we want to create sets of tools that co-ops can make use of to manage their affairs – communications, decision making etc. There are a handful of things that, regardless of the type of participatory community you’re in, it could be a food co-op or a co-housing community, you need to take care of similar patterns.

One of our goals as part of the Commons Engine is to have a “toolkit” of applications you can download and use and combine with one another to create an interoperable system. And we’re planning to give a bunch of this away for free.

OSB: That’s exactly what we’ve been hoping for! It sounds great – I keep hearing from people who say “we need to build a commons platform, we want to bolt together some existing open source tools, so that we’ve got some basic tools like asynchronous and synchronous chat, maybe some document storage and some social media etc”… and I answer “How are you going to do that? It’s going to be hard using LDAP, or similar to enable single sign on and to make these apps truly interoperable” – but what you’re proposing with Holochain seems like a much more suitable framework – could Holochain be what we need to enable cooperation 2.0?

MS: The big difference is this is not a platform. This isn’t about platform cooperativism, its actually about “protocol cooperativism”. “Platform” assumes there’s a thing at the centre. I want to make this demonstrable. Let’s use the simplest example I can, which is about language. Oli, give me a random word?

OSB: Sunshine

MS: OK, let me do the same – I’ll close my eyes… open them again… and Oh wow – “Skeleton”

OSB: The first thing you saw when you opened your eyes was a skeleton!? Now I’m worried. Where are you?

MS: I’m in Mexico – and I’m looking at a picture, of a skeleton.

OSB: Oh, OK! Carry on…

MS: So I’m going to call this the “sunshine-skeleton” chat. Now, if I ask you in 3 weeks do you remember the “sunshine-skeleton” chat you might say “yeah, I remember…” But, if i ask my Mum do you remember the “sunshine-skeleton” chat, she’ll say “What are you talking about?”

What happened there was that you and I just invented new language – a new shared reference. We mutually invented it.

Now, it could be that you invent new language – for a new part for a car, or a way of running, and if you share that new word we can use that to refer to something. But who owns it?

OSB: We do? Well, nobody does really…

MS: Right, ownership doesn’t have to do with use. It has to do with the ability to exclude others from using something. For example, when you own a property and rent it out, you have an ownership claim but no right to use it – the renter has a right to use it and that is contingent on paying rent etc but ownership isn’t about use – its about excluding others. This is really important.

We have a very property-focused society which has decided excluding others from using something is an important tool for how we’re going to steer… but it doesn’t have to be the tool we use for how we communicate.

Right now, when we think of apps, we think of them like places and properties to be owned, but apps (especially the ones we are creating) are really agreements between different parties about how to communicate with each other. Just like you and I agreed to refer to this conversation as the “sunshine-skeleton” conversation… In a peer to peer version of Twitter, where the users agree to structure their message as 140 characters, that’s just an agreement. So if someone tries to type 150 characters, other members of the community might say “No, that’s not an acceptable message”. But they don’t own it and they don’t own the app, they’re just deciding that “according to the rules, that I have agreed to play by, that doesn’t qualify, so I’m not going to store it or pass it along”. That community is able to govern itself without having to create or rely on ownership at the communication level. There doesn’t have to be any resources at the communication and application level. This could be just an agreement – to use this specific way of structuring information to communicate with one another.

So, the reason I bring this up – and why it’s so important is that most folks in the Platform Co-op World look at Uber and Airbnb and say “We could do that too! Wouldn’t it be great if it was owned by the riders and drivers.” But they’re accidentally importing assumptions about ownership and what is needed there – which creates concentrations of power automatically.

They say “Yeah, ok, you might have an admin team but we’ll be able to vote them out if they misbehave…” But, nonetheless, this concentrates power – and it actually has some significant drawbacks…

The main one is that experiments tend to be “whole group wide”.  Whereas if we treat an application more like a language (something that happens to be held by both of the communicators), any two parties can decide to try something different, and if out works for them, cool – maybe it will spread. They don’t need the entire community to go along with it. They are able to try things out on their own and build experience. That enables the community to experiment with new ways of communicating, new ways of coordinating. And the things that work, they propagate – and the things that prove to be a waste of time – people will decide not to copy that one… or they stop using it.

Language is highly adaptable because it’s stored holographically – it’s stored holographically inside the brains and the bodies of each of the participants – and language adapts readily because any person who says “we need a new word for something”, they can come up with that word –  and anyone else who says “oh, that’s so great, that’s really useful” they can start using it. So changes can be tried and spread and at every step of the propagation its spread is dependent on it being useful – functional for those users.

That’s how we hold language – it’s why languages is adaptable.

It’s also how we hold culture – the beliefs and expectations about appropriateness in a given situation. Which means they vary from person to person.

If someone tries something new – like staying in a stranger’s home after they have booked a room on a website – if it works out well they might tell some friends about – and if those other people try it and have a good experience too – that new expectation might spread – that “culture” might change.

We saw this over the last decade with the rise of the sharing economy companies… The culture shifted and it shifted rapidly – that’s because culture is held holographically – it lives in the brains and the bodes of the participants. Holographically means that each party sees the whole from their own experience and perspective. The technical phrasing we generally use is “each part perceives the whole but from its own perspective”.

If we make the way that we hold applications “opt in”, and individually held – the way that we do language and the way that we do culture – we will gain the adaptive advantages of holographic storage.

The main point I want to get across is, for communication and coordination, we don’t have to keep running cooperative organisations as if they are just corporations but also with voting – we don’t have to adopt the top down structures of the corporate world. It’s not that they aren’t appropriate anywhere but they aren’t needed for layers of communications. There are ways we can do the communications infrastructure that doesn’t have to have the centralisation of power or accumulation of assets at that group layer.

By forgoing that – by actually running cooperatively, we gain huge advantages, in terms of our ability to adapt to circumstances in a world that is increasingly volatile, uncertain, complex and ambiguous.

That is the difference that makes a difference – your ability to adapt is the key thing that gives a group not just a competitive advantage, but a collaborative advantage.

OSB: Cool, I get that. But I want to take a step back and make sure we really explain your ideas as best we can. So how would you see an Uber alternative which was structured more organically, following the language example and the  “protocol co-operativism” model you mentioned?

MS: With platform co-ops, you end up creating, not just a way for people to communicate, but a layer at which value or resources accumulate – and then you figure out how to manage that accumulation – how to distribute it. That’s the traditional structure of sharing economy applications.

Platform co-ops have basically proposed “Hey, what if it wasn’t a bunch of venture capitalists that owned it, it was us that owned it?” But they’re basically running the same model. You end up having 95% of the shortcomings that you have in the old model. You may have handled some of the misalignment of interests shortcomings of the old model, but you haven’t addressed the “inability to handle complexity” issues.  They are still there.

The alternative is to do applications the way we do language.

Let’s say right now you have a bunch of different services – combined together to do something like ride sharing. So people have phones with GPS – that transmit a signal – that’s available to drivers. And drivers transmit a signal saying that they can drive… And riders may even include where they are going to… So there’s a layer within Uber or Lyft or whatever, which matches riders with potential drivers. And they match a pair and give the driver 10 seconds to accept “Do you want to pick up this ride?”. And the driver goes “yup” or “no”. Those are all signals, all of these things are different little grammars. Different forms of information.

Another one is matching the requests with the offers – its automatic, the party in the middle, usually through an automated process, decides what to do if that driver doesn’t respond – which other driver to offer the ride to.

Now, if you wanted you could run that instead as several different apps – not one. Several combined into one.

There’s another layer to this – the ratings dance – after the ride, both parties rate each other and maybe make a comment – leave a tip – and do the payment thing – all these layers are currently integrated into one app. But they don’t have to be.

Matching riders with drivers could be separate to payments, separate to ratings – on the backend, that could be its own little app.

And it might be that there’s a general ratings thing that everyone is using, but there’s also custom ratings communities.  So if you’re somebody who’s really sensitive to smell, you might want to pay attention to “Does the car smell bad?”. That’s probably not something that the community wants to subject every user to. Not everyone cares about ratings about smell! That’s OK, but for the folks who do care – they’re going to be glad that they can access the knowledge from the other folks that care about smell.

That could be its own little app.

So with Holochain, because you run the apps on the devices of the users themselves – each user can take a bunch of different apps and combine them together. So, I could be using this application on Holochain – looking for a ride and after the ride offer hits my device, my device can pull additional information from other apps that I am also running: about how is the smell is the car? How talkative is the driver? How safe did his driving feel to the passengers? etc

So, there may be five different things that I’m paying attention to – and maybe I opt not to accept the ride. But you, Oli, on the other hand – you don’t care about any of those things. You see that he has 4.2 or whatever, and that’s good enough for you, so you book the ride.

This is different from the Platform Cooperativism model because instead of there being a layer where assets are accumulating – all we have is some mutual alignment in how we communicate.

OSB: Let’s be clear, when you say “assets are accumulating” you mean, funds in the main Uber “master account”?

MS: Yes, but you could have a payment application that’s an entirely different app. With Holo host, we do have a company account – but you could run a  mutual credit currency on Holochain without any central organisational account. You could have a completely distributed mutual credit currency. We wanted to fuel improvements in that Holo system and to also use revenues from there to subsidize the larger holochain ecosystem, so we are charging a fee when people use Holo.  Of course, unlike Uber or Airbnb or Apple, we aren’t charging 20 or 30%. For both creating the marketplace and running the payment processing, we are charging less than traditional systems charge for just payment processing.

OSB: Remind our readers, how much does Holo charge when someone sends Holo fuel?

MS: One percent or less.  And we expect that despite charging so little, that this will be enough to get this Holochain ecosystem off of the ground.

OSB: So I can kind of see what’s going to happen, you’re going to have all these little apps running on Holo – and presumably we’ll be able to pay in Holo fuel for stuff …

MS: That’s one way. But we also think people are going to come up with lots of other currencies for their own communities. Holo fuel will be one, and it will be an early one so it will probably be wide spread, but people are going to come up with their own.

We think of currencies as just some way of recognising some specific form of contribution.

OSB: OK, so we could have our own currency, just based on an agreement between you and me – but if we’re going to want to grow our network to make our currency more useful – we’re going to need more people – and we’re going to need a wallet to store it in. Are you going to have a specific wallet for managing currencies?

MS: Those things will certainly evolve. Holo host is its own application and Holo fuel is a big part of that application. But we’re not dealing with tokens. It’s mutual credit – So we just count all of the additions and subtractions from your account. Your balance is going to be the sum of all those inflows and outflows – to which you maintain private access – to have the ability to send funds, by holding on to a private key. But we’re not planning on building a multi-currency wallet, at the moment.

OSB: OK, so if we wanted to exchange “Co-op coins” we’d need to develop our own app?

MS: Yeah. And that is partly what the Commons Engine is focused on, by helping a number of different communities develop crypto-accounting systems that foster flows of assets and activities within their own community.

OSB: OK, so what about the login system? I see that Resonate and Rchain have partnered with LifeID, which seems to have given them quite a clever method of managing identity – Does Holo have something similar?

MS: We’re building something called DPKI – which is a Distributed Public Key Infrastructure. I’ll try to keep this brief, as I could go way into the weeds on this one!

Designing distributed systems for the internet is the way I’ve spent the last five years of my life – and to be blunt: most people in that space are doing it wrong. They’re trying to provide THE THING that will be your digital identity.

OSB: Sure, everyone wants to do that!

MS: Right, but it turns out that’s not what identity is. Identity is always in the eye of the beholder – so “who I am”?  If you really want to get at what that question is about, is “who am I, to you”? Who am I in your eyes – and only the information that has reached your eyes and your ears, is going to influence how you behave with me.

At the end of the day the root of identity is correlation; The ability to relate one piece of information with another.

You could bump into a guy and talk about football, then see him again the next day. But if you don’t have correlation – if I don’t realises he’s the same guy, there’s no ability to benefit from the previous interaction. You have to start all over again. Imagine if every time someone met you they introduced themselves again. It would be kinda awkward.

The ability to remember things and to correlate them with one another is core to identity.  “This is Tim. I talked to Tim yesterday. Tim likes football.”

So identity is always in the eye of the beholder – that doesn’t mean it’s not important to do wallet management – and things like that, but it’s different than it’s usually pitched. It’s usually pitched as “This (number in our system or our blockchain or whatever) will be your identity”.

But what we’re really talking about here is how can you reliably be able to create correlations between your past and your present for others, in ways that they find credible? How can I make it so that you believe that that my hospital has confirmed that I am 18, not just that someone is 18.

There’s another layer here. Most of the folks in that space saying “We’ll be the one place where you can come to for ID… blah blah blah” – but there’s another layer which they overlook. What happens if someone breaches that layer? What happens if that gets compromised?

OSB: Good point.

MS: The basic gist is – there’s no such thing as perfect security – it doesn’t exist.

Security alone is this really ambiguous concept. It basically means how do you prevent failure. Well, there are all sorts of ways to fail – everything you do to reduce your risk involves a delegation, some sort of reliance on a process, or person or system – to make you safer – and as a result – you add in some potential vulnerability there.

If I rely on my memory for my password and don’t have any backup – and get hit with a rock on the head and develop amnesia – I’m not able to access any of my passwords anymore – I haven’t adequately spread my risk. Now, if I pass all my password information to my Mum, she can impersonate me – or someone who steals that information from her can impersonate me. But if instead I break the password information into parts and hand parts of it to my friends Billy and Vinay – and I go to six of my other friends and I say “Hey, if anything ever happens to me, these are the people who have the different parts”, that changes things a bit – makes it more difficult to breach. It doesn’t make it impossible. But if there’s no indication that the specific data is a bit of a password, for me – there’s no note alongside it saying what it’s for, it’s just living in their memory and mine – then it’s even less likely to be breached. But there’s always trade offs…

OSB: So that distributed way is how Holo hopes to manage security, by distributing it out… Kinda like the Web Of Trust?

MS: Yeah, the Web Of Trust is wonderful – it’s just never worked, at least not for normal folks. It’s too technical.

OSB [Laughs]: Isn’t that just because it’s never been done properly?

MS: Well… I mentioned I’ve been doing digital identity system for a long time. Two or three years ago a friend of mine started a group called Rebooting the Web of Trust – Arthur Brock and I were part of the original 40 people – and the whole focus was designing distributed identity systems for the internet, that actually work.

Right now that whole community is all wrapped up in blockchain stuff –  They’ve got themselves down, what I would consider, a dead end. They’re telling themselves “Yes – there’s this immutable truth we can get from a blockchain!”

But they’re missing all of the nuance …. it’s only immutable until a breach happens there – and you realise everything is lost and you haven’t built resilience into your systems.

We don’t think that there’s “one right way”. For us it’s really important that individuals go, “You know what – I’m going to handle this bit of risk this way.”

OSB: Makes sense.

MS: But I didn’t actually explain what DPKI is… When I’m running a Holochain application – and I’m using a pseudonym in that app like, Billy7. In another application I could be logged in as a completely different pseudonym, Sally4.

OSB:  You’re going to allow that?

MS: Absolutely, we think it’s really important to allow people to show up exposing only the information about themselves that they want to expose. Other people, or apps, might demand you show up with a certain amount of reputation. Some history, from somewhere.  In that case, it’s up to you to decide whether or not you want to share some specific bit of history, share something else or forgo entering into that particular community or relationship.

So let’s say we have two apps: The ride sharing app and the specific ratings app focused on how smelly was the car. And I’m showing up as two different people in these apps. I can sign a statement using my private keys, stating that I’m the same guy – thus creating the possibility for someone to check that Sally4 is Billy7. “Finkle is Einhorn…Einhorn is Finkle…”

OSB: Errrr “Einhorn is Finkle…”?

MS: Sorry. It’s old movie reference from Ace Ventura: Pet Detective. Anyway, long story short – so you’re able to make these bridges, you can do that without any separate tool. No company needs to be involved.

Someone who is running the ratings app would also have to be running the ride sharing app – or know someone who has access to check the signature. “Was that really signed by Billy7”?  If it was – if they do have some sort of relationship then you can check it and, cool, we built a correlation between these two apps that enabled someone who is running both of those apps to import their history from the ride sharing app into the ratings app to build a bridge and credibly establish that that’s me. Now it’s up to the other parties whether they decide to rely on that but most of them will probably say “ok, that looks good to me”.

All of this (the ability to bridge between identities in different systems) is actually baked into Holochain as is.

DPKI solves a slightly different problem.  DPKI has to do with the question of “What if I want to change my key?”. Basically, it enables people to declare early on in their use of a system how they intend to revoke or replace a key should the need arise later on, and gives them some mechanisms for communicating about that.

Say I’m running this app and my key gets compromised somehow – How do I change the key? Now, in most of these systems they go “Oh! You just trust us, the company! We’ll create a new key for you.” But you’ve accidentally centralised power again. With Distributed Public Key Infrastructure, when you set up your key initially you indicate what the process is by which you’re going to be able to revoke that key – or replace that key. You decide. And that process could be “this key trumps this other key”… or “if 3 of my 7 family members go through this process”… or “I trust this company”. There’s a number of patterns you can run here, but how you allocate that responsibility – i.e. how you manage that risk, is up to you.

Now it’s up to the other parties whether they find your replacement credible but most of the time they will probably say “ok, that looks good to me”.

However, if you see someone change their key 3 seconds before they ask you to wire them £10million – you’re probably not going to send it, you’re going to back up a moment and do some extra things to check and make sure everything is kosher.

OSB: I get it.

MS: There’s the real world of bodies and these information system – and we’re trying to figure out how can your bridge those two worlds in a specific context – so the parties that are interacting find it trustworthy. And that’s going to be different in different contexts.

OSB: Right

MS: If we’re launching nuclear weapons we’re going to have much higher security protocols than if we’re sending a text message.

OSB [Laughs]: I hear you! Hopefully we won’t be launching any nukes. I wanted to ask about bundling apps. My question is about running a specific co-op. You mentioned that you were building tools for co-ops… So, say we run a maker space – we’d need some obvious tools straight away: we’d need our synchronous and asynchronous comms, our document space so people can work on shared files – we’d need payments…

MS: You’d need to be able to track if people had paid membership dues… and hours used and available on the machines…

OSB: Exactly, so my question is, if I was to use the Holo tools – would I need to form a legal organisation outside of Holo in order to be incorporated and use the Holo tools or could I actually just assemble a group of predesigned apps in my Holo workspace and say “You know what, we’re not actually going to incorporate as a legal entity at all, we’re going to use the Holo system, everybody who wants to transact with us, log on there?”

MS: Yes, that’s very much our intention. In the Maker-space example – if there are physical assets they’re controlling, there may need to be some kind of legal entity. Simply because the state won’t recognise your property rights otherwise… But let’s make it a distributed make space – it exist in the garages and basements of the various members – Jim has a lathe and Marcus, three doors down, has a laser cutter, Philip has welding equipment – all these different people with their own property who’ve decide to cooperate. Let’s assume they’re not collecting fees – so some of the things you would need now would be “What are the hours of availability for a specific resource?”, “What’s the status of that machine?”, “Is it in working order or in need of repair?”. And you’d probably want some way of recording time, “I want to book for this hour”. You want some way of either organising maintenance or recognising people who have done maintenance. You’d probably want to track usage – how much are you using other peoples equipment… etc

Every one of those layers you could run as a Holochain app – and you could have them all interacting with one another as if, from your perspective, it was a single Holochain app. Even though on the backend, each one is its own separate community.

OSB: Right, so in order to deliver that experience to the users of the Maker-space gang – someone is going to have to bundle all the little apps together. Presumably there’s going to be some simple tools like task management, people management, equipment management, maintenance management… And as more and more Holochain apps become available presumably they will act as further building blocks… So if someone wants to start a Co-op and we know already there are existing Holochain apps which do elements of the things we want, how do we go about bundling them together and delivering the services we want?

MS: Right, you could bundle them all together – and your users would download your bundle – that makes all those different micro applications into one meta application – so users access the micro apps through the meta application and that would give them a useful starting point. But if any of the user want to add to this – they can customise it – they would be able to change things to better suit their needs over time.

OSB: OK. But, let’s be clear on that, how would they go about customising the “meta app” – or pulling new elements into it?

MS: Let’s say that some of the members are really into 3D printing – but its really annoying to be changing the spool of thread all the time – so instead they agree to just keep track of how many minutes of printing you did – and charge you for that. And that could be via a separate payment system application – which might be doing all of that settlement in a cryptocurrency like Holofuel. Settling fees directly between members without any assets being held at the application layer – there’s no ownership that needs to happen there. My point here is, if you and I were running the 3D printing cost sharing app as part of our larger distributed Maker community app – it would just be a part of that app for us. But other people may not necessarily make use of it – they might not know it was there – but they might be offered it when they updated the app.

For us that’s really important – for the community to be able to innovate in disjointed ways. For you to go off and try something new and if it works to keep doing it… And for me to go off and try something new and if it works I might keep using it. But we don’t all have to be running the same thing as each other in order to communicate. As long as we’re running some layers – as long as some of the layers are in alignment then we’re able to communicate through those channels.

OSB: I’m getting it. But, not everyone is a coder, so if I decide I want to add a new kind of rating – how would I do that? And if everyone’s got all all these customisations, how do other people find out about them?

MS: Well, if you have people communicating with one another – in the Maker-space example they’re literally going over to other people’s houses, so they’d say “Hey have you tried this yet?”. That’s how most things spread, but we’re planning to create an app store – of Holochain apps. That’s not going to be the only way to get a Holochain app – You could build an app and just share it with your friends. You could even build your own apps store but because the Holochain app store will be the first it will probably be the most populated.

As a little time goes by, we’ll work to make it easier for ordinary people to take a new app and pull it into an existing app – That could get to the point where it’s almost drag and drop.

There’s all sorts of things that we’re planning on doing in the next couple of years – based on work we have previously done at Ceptr – which will make connecting protocols really easy. But, right now, we’re not quite there.

That’s actually how we spent the bulk of the last 10 years – we spent 7 years working on creating automatically interoperable systems – mapping out how to build and building this kind of “hyper-interoperable future”.

OSB: What is the timescale for all of this – It sounds like the Holy grail when you talk about co-op tools being drag and drop like that – How soon are we going to be able to play with this stuff and how soon will we be able to use it with vengeance?

MS: People are building Holochain apps right now. We’re hoping in the next few months to have some of basic chat tools come out as Holochain apps.  We’re “dog fooding” – meaning we’re using the tools we are building because we have a distributed team – and that has its own headaches… So there’s a tool we’re working on right now which we’re calling “Abundance of presence” – it’s about trying to make it feel like we’re all together even though we’re spread across the world.

But in terms of interoperable apps – for the geeky folks in a few months – then end of the year – a decent number of larger applications starting to get used. For the non-geeky folks – it will probably be at least 6 months – and mid to late next year before people who are non-geeky are changing applications easily.

Hopefully in the following years, we’ll be having the next layers coming out – the first slice of that is coming from the Ceptr project – what we’re calling a “Protocol for Pluggable Protocols” (P3) – we worked on this a few years ago and got to a prototype and proved that it worked. Then we stepped away to go and build Holochain. The Protocol for Pluggable Protocols is way more complicated than Holochain, but we think it takes us another big leap forward. But for now, people having control over their own ways of communicating is a critical step, and that’s what we’re enabling with Holochain.

So long story short, Holochain is powerful now. It gives those who use it a big collaborative advantage – and in the coming years, additional projects should improve that advantage even more.

Our hope is that this results in ways of coordinating with one another that are not only more effective, but more human as well; That this enables us to coordinate at even very large scales, but in ecosystemic ways rather than hierarchical ways. That should give these new communities big learning advantages over traditional forms of organization, and with luck, might actually start to shift humanity away from some of the erosive patterns that have been creating downward spirals for so long, and instead start making use of much more regenerative patterns.

But we’re running short on time. The old economic models have been so destructive. We’re putting in the work to try to shift to a more thriving paradigm. One that works better for people and for planet. It’s not a guarantee that it will work, but for those of us in the Holochain community we don’t really feel like we have a choice. We have to try. Fatalism is seductive, but not very useful – and honestly, not very fun.

For me personally, and for others on the team as well, this work has felt like a life’s calling for well over a decade. This is a grand challenge, and it feels consequential. It’s been an incredible journey thus far and I’m really looking forward to the work to be done and the lessons to be learned alongside all these other wonderful communities over the coming years.

Thanks for bringing so many good people together for OPEN 2018, Oli! I’m really excited for the event!

Matthew and Art, from Holochain, will both be speaking at OPEN 2018 in London on the 26th and 27th of July.