Summary
We’re currently updating all of our source code and documentation to reflect the recent name change of the runtime from ‘Container’ to ‘Conductor.’ We’ve also finished two more chapters of the guidebook; coincidentally, one of them is all about Conductors. In addition, links can now be deleted, we’re refining our development cultural practices, and the prep work is being done for end-to-end security and data integrity. Lastly, if you’ve been frustrated or scared off by Rust, be sure to read the Holochain 101 section in this Dev Pulse.
Note: Unless otherwise mentioned, all features and bug fixes are currently available in the `develop` branch for trailblazers, and will be included in the upcoming `0.0.4` release.
Highlights
1. Holochain 101: Do I Really Have to Learn Rust?
2. Stack Overflow: Expand the Holochain Knowledge Base
3. New API Functions: `remove_link()` and `sleep()`
4. Guidebook Update: New Chapters on Testing Conductors
5. Keypair Struct: Preparing for New Security Capabilities
6. Cultural Principles for Development
Details
1. Holochain 101: Do I Really Have to Learn Rust?
Our development teams have grown to love Rust for its beauty — and despite its warts. Others feel the same way; Rust came out on top in Stack Overflow’s Developer Survey 2018, and many crypto projects are adopting it for its WASM support and strong compile-time guarantees of memory and type safety.
But we have to admit that Rust is hard. Its syntax isn’t particularly beautiful. You have to be explicit in every type conversion, and most difficult of all, the rules about variable scope and sharing.
We hear your feedback and take it seriously. We have always wanted Holochain to be accessible to a broad base of developers. As Lawrence Lessig famously said, code is law, and we don’t want to restrict this lawmaking power to a select few.
We’ve had requests to support a lot of languages, most popular being JavaScript, particularly in its TypeScript incarnation. Python is a close second. So far, our stance with Holochain-Rust has been to support WebAssembly and lean on its active community to develop support for languages. AssemblyScript, a TypeScript-like language, is showing a lot of promise, and their core devs have been immensely responsive to us. However, it doesn’t yet support some crucial features, like closures and untyped objects, which means that you can’t use most existing JS or TS libraries in your DNA.
So where does that leave you, our faithful developer community?
We’re still looking for the right solution. JavaScript is very much on our radar.
The current issue is trying to make the best choices with short timeframes and a small, focused dev team.
But wait! You can still use JavaScript — or any language you like. A Holochain DNA is supposed to be a very small, tightly scoped piece of code. Your zome functions and validation callbacks can’t call the outside world, with the exception of other nodes on the network. Their purpose is to simply bear witness to the actions of a user and make sure those actions conform to a small set of rules. Therefore, they probably shouldn’t do complex things like audio processing, image manipulation, or machine learning.
If you compared Holochain to multi-tier architecture, your DNA would contain the most critical pieces of the domain layer, as well as the persistence layer. In terms of scope, each DNA should be written as a microservice. We’re also building a suite of core services and DNAs you can use in your applications.
What you normally think of as an ‘app’ will most likely consist of one front end, coordinating interactions between a collection of DNAs. The front end could handle data-heavy tasks, interfacing with external web services or IoT devices, GUI presentation, and most of the business logic. As such, the DNAs you write might only be about 10% of your app’s code.
You can read more about our vision for the architecture of Holochain apps in Nico’s Reinventing Applications article.
Holochain’s RPC-based container interface makes it easy for any local process to act on an agent’s behalf. The most common use case would consist of a web or native GUI — but we encourage you to get creative! For instance:
- A cronjob running a cURL command that buffers or reposts your social media messages.
- A Node.js service that collects temperature data from your homemade Arduino thermometers and reports it to your weather hApp instance.
- An alternative GUI for power users or people who use assistive technology.
- A bridge between a currency hApp and a user’s bookkeeping application.
- A bridge between a Holo fuel instance and a blockchain node.
- A plugin in a legacy web-based platform that enables all of its members to connect to Holochain services via the platform’s privately run Holo host.
- A public web gateway with read-only privileges, like the one that the clever folks at humm.earth have created for their Holochain-powered blog.
The non-DNA parts are arguably the most important parts of your application, because they bring the most value to your users.
As long as your DNA is well-written, it can happily remain the most boring thing in your stack.
“So we still have to write a little bit of Rust code?” For the time being, yes.
We think Rust’s strictness fosters highly-disciplined, thoughtfully written DNA code. This is important because the shared laws that bind a network of agents should be as bug-free as humanly possible.
So far our app dev teams have found that the really confusing part of Rust, data ‘ownership,’ doesn’t actually come up much because DNA functions have a limited lifetime and small scope. What’s left is a rich, expressive type system and strong compile-time guarantees of correctness — and a syntax that only a computer could love!
As for the future, we’re still working on making it easy for you to write DNA code that doesn’t open up security vulnerabilities. We’re considering various options for integrating JavaScript, as well as other exciting possibilities like being able to write all your entry types and data access code in GraphQL SDL. We encourage you to come to our Holochain Mattermost Chat and contribute to the exploration and decision-making process.
2. Stack Overflow: Expand the Holochain Knowledge Base
Help us grow the Holochain knowledge base on Stack Overflow!
Submit your Holochain question.
Submit your Holochain Rust question.
3. New API Functions: `remove_link()` and `sleep()`
With the addition of the `hdk::remove_link()` function, links now have a full set of CRUD functions — or rather, just ‘CRD’, as links aren’t meant to be modified. Additionally, if you have any need to pause DNA execution temporarily, you can now call `hdk::sleep()`.
4. Guidebook Update: New Chapters on Testing Conductors
We’ve finished writing the next two chapters of the Holochain Guidebook. Chapter 6 covers how to write and tests for your zome functions using the Holochain-NodeJS library, which is a conductor specifically meant for spinning up multiple copies of a DNA instance for testing purposes. Chapter 7 covers Conductors: what they are for, what functionality they expose, how to get clients to use them, and how to configure and run the development and production Conductors.
We’re excited about these chapters, because they delve into important subjects that have thus far only been mentioned briefly.
(Note: The chapter links above point to the draft version of the documentation. Documentation updates are synced with the `develop` branch, so you’ll see this content in the live documentation site when 0.0.4 is released.)
5. Keypair Struct: Preparing for New Security Capabilities
Holochain’s first principle for trustable, distributed computing is intrinsic data integrity. What this means, in a nutshell, is that the data itself carries guarantees that it can be trusted. One of the foundations of intrinsic data integrity is that every piece of data is signed by its author; this allows you to detect forgery, tampering, and impersonation, as well as prove authorship of a disputed piece of data.
As mentioned in a previous Dev Pulse, we’re using the Sodium cryptography library, which provides a high-performance implementation of the industry’s most trustworthy cryptographic algorithms. We’ve already done a lot of work on the DPKI library; it generates encryption and signing keys, handles revocation of keys when a device is lost or stolen, and provides continuity of identity across different devices. Currently, we’re working on a pull request to bring keypairs into Holochain-Core so that chain entries can be signed, clients (such as GUIs or Holo Host users) can prove that they’re allowed to access a Holochain instance, and DHT network gossip can be encrypted.
6. Cultural Principles for Development
We’ve been talking a lot about cultural practices for Holochain-Core development and have decided on formalizing them into a set of principles. They’re important to both our core dev team, and the people who wish to contribute to Holochain-Core, but we also believe they’re good guiding principles for DNA developers. We’ll share them in their entirety when they’re finished, but here’s a preview:
- Best practices for making code review an efficient process
- Standards for Test Suite
- ‘Make impossible states impossible’ — that is, when an action or state shouldn’t be allowed, design your functions and types so that the result is a compile-time error. This is especially important for validation rules in a DNA.
