Beyond Mere Decentralization — The Orthogonal Web
--
With so many cutting edge technologies being developed, from blockchains, DLT, DAOs, to IoT, stacks, and DApps, it can be hard to keep track. Let’s take a step back for a second and ask the question, why should anyone care about any of this? What even is decentralization and why does it seem to be the only system characteristic any one is talking about? Let’s begin with a trip back in time and explore concepts beyond mere decentralization.
The ARPAnet, a DARPA.mil Creation
Advanced Research Projects Agency’s Network
Recall that the ARPAnet (progenitor of the Internet) was funded and implemented so that U.S. war fighters could employ encrypted intranets and low-bandwidth communications (using TCP/IP) to better defend against a nuclear armed Soviet Union. It enabled decisive decision making by offering commanders near real-time information exchange and “command & control” (C2) systems. Due to it’s generalizable nature, the applications of this technology were endless.
Once trained and equipped, soldiers could quickly relay messages, maps, images, unit reports, orders of battle, and plan operations spanning many locations at once. Having interoperable “high-level” protocols meant that the kind of I/O link or a link’s security integrity was no longer critical because security and data packaging occurs in the layers above TCP. In other words, these open and pluggable protocols meant that unsecured lines of communication could now be used to transport sensitive information.
“The goal was to exploit new computer technologies to meet the needs of military command and control against nuclear threats, achieve survivable control of US nuclear forces, and improve military tactical and management decision making.”
-LUKASIK, STEPHEN J. (2011). “WHY THE ARPANET WAS BUILT”. IEEE ANNALS OF THE HISTORY OF COMPUTING. 33 (3): 4–20. DOI:10.1109/MAHC.2010.11
The idea of “centralized control, decentralized execution” began taking root in military doctrine once some of these foundational systems were in place. One of the ways this doctrine manifests to accomplish the stated goal is in the adoption of software/hardware tools and interfaces that are secure and easy (enough) to use even for Private Pyle and Airman Snuffy, who at the time had likely never seen a computer. With network privacy built into the system using end-to-end encryption, the task of sharing information was made much more simple; however, not quite simple enough.
The Topologies of Decentralization
Internet Relay Chat, or IRC, was one of the first widely deployed chat protocols that improved communications between commanders and field units using secure, multiplexed chat channels adaptable for any team (just ask Slack how awesome it is). The U.S. Army, Air Force, Navy and Special Forces use IRC to this day in places like Afghanistan and Iraq to send and receive urgent messages such as 9-line medical evacuation (MEDEVAC) reports, troops in contact (TICs), resupply efforts, and to support quickly unfolding activities and decisions. IRC is just one example of a simple and flexible tool that’s highly effective, as long as you can implement and secure it.
From C2 to C5ISR — — A long and historic journey of developing command, control, communications, computers, cyber, intelligence, surveillance, & reconnaissance collection and sharing capabilities within a trust network.
“Decentralized execution is defined as the ‘delegation of authority to designated lower-level commanders’ and other tactical-level decision makers to achieve effective span of control and to foster disciplined initiative and tactical flexibility.” CENTRALIZED CONTROL AND DECENTRALIZED EXECUTION, VOLUME 1, BASIC DOCTRINE; CURTIS E. LEMAY CENTER FOR DOCTRINE DEVELOPMENT AND EDUCATION. DOI: 27 FEB 2015
It’s important to identify, there are different contexts in which decentralization can arise, from an organization decision making perspective, the physical infrastructure of a network, to a software’s architecture implementation. All that to say, terms like “decentralization” and “distributed” actually aren’t that helpful without also having all the appropriate context of how the systems are put into practice. So far, a lot of the “decentralized” software solutions we have seen released (or are in the works) either depend on web technology (we’ll talk about why that’s a problem shortly), or require a major engineering endeavor to be harnessed usefully. Although these new “cloud” technologies make using and sharing information vastly easier for end users, there are still major privacy and accessibility gaps.
Even some of the most widely recognized “decentralized” infrastructures aren’t necessarily as decentralized as they appear (ref: Bitcoin & original research by Cornell); additionally, they can require restrictive licenses, have closed code bases, require buy-in on others’ business or governance model, or assume that a seven-figure engineering budget is at the ready. The questions I always like to ask are, who owns the data and where does it reside? Identifying this pattern can be the first step in trying to decide where you or your community fits into all of this confusion progress.
For a deeper understanding of the subtle differences between decentralization and distributed systems, check out this article by Julia Poenitzsch entitled What’s the difference between Decentralized and Distributed? And how does this relate to Private vs. Public blockchains?, published on Medium, Oct 3, 2018. She appropriately concludes “there are degrees of decentralization and distribution, rather than hard divisions. How much decentralization or distribution is desirable then depends on your objectives.”
Making Use of the Tools We Have
It’s no coincidence that tools with profound utility are also broadly applicable to people everywhere, whether in business, emergency response, or “going off to college”. Today more than ever before, the importance of being able to connect and transact easily, dependably, and securely is paramount, whether or not it’s obvious. Both the military intelligence community (MIC) and the Silicon Valley behemoths were created on the backbone of open source initiatives like Linux, TCP/IP, HTTP, and HTML protocols. How did so many people (the non-technical masses) miss out on owning and employing these tools directly?
It has become all too easy to rely on a handful of platform gatekeepers. Historically the field has been dominated by MSFT, APPL, and GOOG, with device-specific operating systems and web browsers as the de facto standard. But with the rise of powerful open software languages, distributed computing, and 3D graphics, the equation is rapidly changing. So how does PLAN compare to other projects that offer hope of more resilient solutions? Major developments efforts are underway in this naecent space, including projects like Holochain, Polkadot, EOS, Hyperledger Indy, and others. Can PLAN work with Holochain or other distributed infrastructure layers?
The short answer is yes, with some integration work, Holochain for example (a distributed infrastructure for creating peer to peer applications) would be able to plug in to PLAN. But I think it’s pertinent to keep in mind that the peer-to-peer infrastructure that you decide to use is part of a much larger integration puzzle. It’s also important to make these infrastructure and data tools usable (e.g. with an interface) by communities and their members for building their own resilient networks, with flexibility to centralize or decentralize depending on needs.
Is ______ THE solution?
Holochain has emerged as a flexible DLT foundation offering a decisive advantage over proprietary/closed DLTs. Holochain provides infrastructure for developers to build apps on their peer-to-peer “DHT” layer called a distributed hash table. Like PLAN, Holochain features a private instancing model, meaning that any group or community can use it without becoming otherwise dependent on other people, groups, or organizations. In contrast, many DLTs ultimately keep a proprietary element behind lock and key, a paywall, or entwined with a digital currency. It’s important to point out that PLAN works together with existing DLT / Blockchain layers that are compatible with our architecture and Design Principles. PLAN is a kind of technology glue that brings the components of a system all together, including infrastructure, a complete security data-model, and interfaces (UI/UX).
PLAN IS A KIND OF TECHNOLOGY GLUE THAT BRINGS THE COMPONENTS OF A SYSTEM ALL TOGETHER.
Holochain = Distributed Infrastructure
PLAN = Hybrid Network Operating System
A component based approach works well for PLAN because it allows the end user to choose a configuration for their local needs, whether on or off-grid. As we’ve seen in many blockchain-specific architectures, what happens when the community’s needs outstrip the conceptual models imposed by the distributed ledger layer? What happens when the models used at the distributed ledger layer are inherently too much complexity for community end users? And regardless if we all agree on how pluggable the bottom-most infrastructure should be, what about usability? If there hasn’t been an intentional vision or plan about a device operating system AND infrastructure-agnostic user experience, then how far along are we really?
According to the Holochain website,
Is there anything in that list that might be challenging for a group of non-technical users? With these barriers to entry in mind, it’s possible relying on Holochain alone will make communities less self-reliant if people and communities are depending solely on the Holochain developer ecosystem to derive privacy, credibility, trust, identity, and for an application to continue working. Maybe you are ok with some dependencies if you are deriving value from a particular network, or using the infrastructure to integrate with specific kinds of applications, but then there is still the task of building an interface for all the different OS’s and Browsers that are out there. Which ones do you target?
Techno-Socratic Dialectic
Is it realistic that all communities will forever find Holochain the ideal secured storage system? What is the cost of finding that out the hard way? Do we just discard the principle that a key part of this tech is that communities choose the right components best for their needs? A team of journalists doing a high-risk expose are correct to demand a peer-to-peer storage layer that will have rather different security and performance trade-offs than, say a community healing center, a city block organizing a weekly flea market, or a crafting guild needing only the most basic functionality.
Why Not “Decentralization”?
It connotes a process to disrupt the status quo… but suggests no vision of a better thing to replace it with.
It suggests a topological fix… but are our true problems merely topological?
– Peter Wang, CEO of Anaconda, Lightning Talk at DWeb 2019
So what’s next for “decentralization”? Is it going out of style before it even got popular? I would say yes, hopefully for all of our sake. There is actually a much more nuanced and actionable approach available than mere decentralization. While there is no common parlance that I can reference to provide an immediately satisfying understanding, I will refer to this approach as The Orthogonal Web, a concept coined and articulated by Peter Wang, CEO of Anaconda, during a lightning talk at DWeb Camp 2019 (led and sponsored by the Internet Archive).
The Orthogonal Web
Peter points out there are “three critical elements of a communication and information system that need to be held orthogonal to each other”: Data | Transport | Identity. Key to understanding this Privacy Trinity is that “all three legs affect each other, but all three legs need to be put together in an orthogonal way … 90 degrees from each other so they can not be used to capture the other.” For example, if you are sending a sensitive email using a transport method that relies on Gmail infrastructure, which retains part or all of your message on their servers, the identity and content of the message is tacitly exposed to Google, and by extension any one else that is able to gain access to those lines of communication. The key takeaway from Peter is that with any conventional infrastructure built on top of the Internet (aka ARPANet), that orthogonality does not exist.
Data, Transport, Identity
“ALL THREE PILLARS EFFECT EACH OTHER, BUT ALL THREE PILLARS NEED TO BE PUT TOGETHER IN AN ORTHOGONAL WAY … 90 DEGREES FROM EACH OTHER SO THEY CAN NOT BE USED TO CAPTURE THE OTHER.”
Resource Mapping and the Consent of the Governed
With the latest unfolding global CORONA event, and the obvious need to build scalable resilience mechanism into our social safety net, we no longer have the time or luxury to ignore the current gaps in privacy, accessibility, and collaboration. Now is the time to harness these systems specifically for communities, and to put forward new strategies for localized rapid problem solving. As an example, I started making a map of Austin years ago to identify the developments, resources, and other critical environmental intelligence (like fire stations, farms, health services, parks, libraries, as well as art and amazing spaces). Maps are the answer to a critical question: “What is in my environment?”. The purpose driven idea that has carried over into PLAN is to create a robust information platform that fosters resiliency of shared habitats and local relationships through collaborative mapping and exploration.
Resource mapping is indeed one of the high utility applications that can be harnessed with spatially collaborative systems; however, who owns that data and where does it reside? People are right to hold skepticism of a system that is designed to, let’s say, track all the money, resources, or the infirmed. There’s this really important human aspect at the heart of the matter that is rarely talked about called Consent. Unless a consent relationship to be part of a data sharing community (or any community for that matter) is fostered, and an agreement that governs the span of control in such a system is fully articulated and checked, then all we’ve really accomplished is creating additional moral hazard to navigate.
At PLAN Systems, we have gone to great lengths to factor in these realities to engineer a platform that is modular and pluggable, including the encryption AND storage layers, extensible core functionality, all the way to the interfaces that make the functionality accessible to end users. PLAN’s open and pluggable architecture stands up to Peter’s Orthogonal Web approach, and provisions for all thee vital aspects of an end user’s data footprint — data, transport, and identity.
PLAN is a new class of technology, a collaborative operating system that is not device specific, and is community-centric (e.g. transport, data, and identity are decided at the community level). Furthermore, PLAN infrastructure enables the latest AAA 3D game engines to plug-in to this hybrid data-model. This model takes advantage of the latest advances in distributed peer-to-peer and swarm technologies without locking you into a particular system or platform component. Ultimately, any other compatible layers can be plugged in as a component in PLAN’s data-model, like plugging in a highly advanced hard drive or adding an expansion bay to your computer.
PLAN Systems — Community-Centric Collaborative Systems
PLAN Systems — Creating self-hosted, hardware agnostic solutions for dependable communications. To confront the challenges of this century, people need tools that facilitate secure communications and collaboration which are not dependent on a gatekeeper, a business model, or internet connection to continue functioning.
10 Design Principles for Future Technology Systems
If you found this information useful, please consider supporting our effort.
PLAN SYSTEMS ⏣ 2020
501(C)(3) | 83–0636676
ALL RIGHTS RESERVED
