I've always thought that, for better or for worse, systems and organizations shape each other. A federated system supports a community and tends to be described in terms of format, algorithm, and protocol. Anyone can participate in development, and resources are mutually shared; no single person can veto an experiment in innovation or growth. This is a powerful idea. Contrast this with a centralized system, which today tends to be described in terms of a URL, a server, and the single organization that owns it. In a centralized system, the owning organization must ultimately make the decisions and pay all the bills. Sole ownership creates an unavoidable time and funding bottleneck, stifling independent innovation and growth. We see these limitations play out over and over again in large enterprises, and most startups, whether for-profit or not, fail due to these natural limits on execution. Conversely, those startups that do succeed tend to be those that rely in some way on network effects. The Internet's early developers stumbled into a system and organizational design where anyone can contribute, where decisions are made by rough consensus, and where both innovation and expenses are distributed. The Internet Engineering Task Force is the organization that loosely steers the development of the Internet, and is an unincorporated all-volunteer community with no membership list. The IETF uses the RFC process for decision-making. For those things that absolutely must be centralized, such as renting conference venues, IETF members formed the non-profit ISOC to act as their legal and financial representative. I've spent a few decades trying to figure out how to apply these lessons learned to small projects and companies ("small" being defined as anything smaller than the Internet). A useful question is: If we were to start an IETF-like organization today, using current technologies, what would it look like? The answer to this question has been a moving target as long as I've been asking it, mostly because of the rapid evolution of technology itself. But I think two related events form cusps in the target's trajectory: First, strong cryptography was demilitarized by Executive Order 13026. Next, the resulting innovations in cryptography then enabled practical distributed systems, ranging from secure use of the web to decentralized financial systems. For all of the attention the latter has been getting in recent years, I believe we are still seeing a technology in its infancy. Despite the hype currently surrounding cryptocurrencies, I think it's safe to say that, if an IETF-like organization were established today, it's entirely possible it would use a distributed ledger with crytographic hash chaining to preserve and provide storage of record for both docs and code, as well as for hosting the workflow of consensus formation and decision-making. Many of the protocols and procedures which make up the Internet would be completely different if created today -- easy examples are the registration systems for IP addresses, domain names, and SSL certificates. Making these more decentralized has always been a struggle, because we did not historically have a legal foundation allowing the cryptography needed to build secure distributed systems. Our hypothetical blockchain-based IETF might do much of its own computing using distributed virtual machines, with libraries of algorithms implemented as "serverless" lambda functions hosted on a blockchain. It's likely that the reference implementations of common protocols would be executed directly this way. Last but not least, the IETF is already a rudimentary decentralized autonomous organization, held together by the RFCs as well as customs and courtesies that are generally accepted by the community. If re-implemented today, much of this workflow could likely be implemented as smart contracts. As of today we may not know how to overcome the security concerns that exist in complex persistent contracts; a lot of people are working on this though. I have some ideas myself, and plan to describe some of them here. The chicken-scratchings in this git repository are my own feeble attempts to answer these "what if" questions for my own businesses, as well as for the other organizations I am involved with and may be able to foist this stuff upon. The original repo contents came from me pulling together code from various directories on my hard drive, putting most of it in the lab directory for now. If you are interested in either helping to develop or in being a guinea pig for this project, then interact with the github project in some way, or ping me @stevegt on twitter. If you are one of the NoM folks, you should also be able to reach me via slack.
Roadmap
A distributed-ledger system suitable for hosting smart contracts and running on IoT devices. A few example applications:
- Organizational governance
- Workflow
- Training and certification
- Accounting
- Inventory control
- Door access control
- Machine lockout
- Membership
- Reservations
- Data storage and backups
- Operating system and disk image management
- IoT
We accomplish all this using a (relatively) simple model: Distributed applications (dapps) running in Linux containers managed by a distributed ledger, hosted in a distributed version control system that performs content-defined chunking to store and ship around large blobs, including the container images themselves.
The development roadmap, then, is (relatively) straightforward: Implement things in reverse order of the above paragraph. Beg, borrow, and paste where possible, take advantage of existing code and libraries such as libcontainer, ledger-cli, and libgit2, and become self-hosting early.
Compared to e.g. Ethereum or HyperLedger, we target more of a git-like version control model, allowing forking and interbranch consensus, rather than a single linear blockchain. For turing-complete smart contracts, we simply use Linux containers -- this allows dapps to be written in any language executable on Linux.
We'll use test-driven consensus (proof of merge), where new blocks are tested by one or more dapps, rather than use a hardcoded proof-of-work algorithm. Not requiring a compute-intensive proof of work means single-board computers such as BeagleBone or Raspberry Pi can host full nodes.
Example
Maker space door access control, for instance, could be based on an existing open source project such as https://github.com/makeitlabs/doorbot, living in a container, with modifications to have it communicate with membership, accounting, and certification dapps, each in their own containers. All of this runs on localhost, as opposed to talking to a central SQL db on a server somewhere else. Each door can have its own Raspberry Pi-sized host. These will check and log access events as usual even during network outages, and the distributed consensus protocol will merge records when the network comes back up.
References
Shares a few concepts with HyperLedger, Ethereum, Docker, Ledger-cli, git, and git-annex. Builds on earlier work and prototyping at github.com/stevegt/librabinpoly and github.com/stevegt/git-devops.