Summary
This week has been a refreshing opportunity to do a lot of ‘invisible’ work — exploring architecture, mapping out and understanding complexities we’ve uncovered, and so forth. We’ve also been getting comfortable with our new release process and happily welcomed our new DevOps engineer.
Highlights
- Capturing Complexity and Mapping the Adjacent Possibilities
- API Feature: Signature Verification and Low-Level KeyStore Support
- Holo Enablement: Live Instance Booting
- Developer Experience: DNA Unit Testing with Rust HDK
- Breaking Change/API Feature: CRUD Validation
- Challenges: Synching the Release Process and DevOps Support
Details
1. Capturing Complexity and Mapping the Adjacent Possibilities
The KISS Principle — no matter what you say those S’s stand for — is axiomatic to developers. Simple concepts and simple code makes for easier management of your codebase. However, every project has a measure of irreducible complexity, and it turns out, that building a new distributed stack for the Internet has quite a lot of it.
We’re taking design cues from living systems, wherein many entities employ simple rules to govern their interactions. These base rules result in surprising complexity, and often even emerge from lower-level complex systems. This complexity is actually an asset to living systems — it’s what allows them to adapt to threats, thrive, and give birth to the wonderful richness we see all around us.
Much of the complexity of Holochain’s design space only gets discovered as we go — as we explore things that appear straightforward, they unfold into webs of sub-problems. It can be difficult to keep a view of all the interwoven pieces.
We’ve been doing a lot of behind-the-scenes work this last week, mapping out all the complexity we’ve uncovered so far. We’ve produced a lot of architectural diagrams and documents in the process. However, the ultimate result is not pieces of paper — it’s confidence. We know where we’ve come from and we know where we’re heading next. Every bit of complexity, when understood and written down, becomes a known thing.
This mapping, reflection, and exploration makes for a more robust design. It’s good to be entering this phase right now.
2. API Feature: Signature Verification and Low-Level KeyStore Support
Cryptography is at the heart of Holochain’s design; it’s what allows participants to put their trust in the validity of the data they see. Public-key cryptography — specifically signatures — are one of the core primitives for building intrinsic trust in data.
Holochain attaches a header with a signature to each piece of data at the ‘subconscious’ level, however, a lot of use cases need in-app signatures as well.
The next alpha release will see the addition of the `verify_signature()` function as the complement to `sign()`. This brings us closer to feature parity with Holochain-Proto. It’s quite exciting, because important apps like DPKI and HoloFuel rely heavily on data signed by two or more keys. If you’re designing an app that requires countersigned transactions or third-party guarantees — such as contracts, currencies, and identity verification — these two functions are crucial for you.
As a person uses more Holochain apps, they’ll generate a lot of keys that represent and control their identities on the networks to which they belong. DPKI is a core app designed to manage those keys. Sometimes it needs to sign data with keys from other apps. We’re currently building low-level support for a ‘keystore,’ which holds all of a user’s keys on a device and makes them accessible to the appropriate apps. Note: This feature will be in 0.0.8-alpha.
3. Holo Enablement: Live Instance Booting
As we ramp up our Holo Closed Alpha testing, Holo requirements continue to push Holochain features. There is a conductor admin API endpoint, `admin/instance/add`, which allows you to create an instance of a specific DNA. The Holo Hosting Interceptor, which spins up new instances on hosting devices on behalf of web users, uses this endpoint to do its work. Thus far, it had only written entries to the config file, which meant you had to restart the Conductor for the changes to take effect. Now, instances are created immediately. Note: This means that they’re instantiated for a user, not actually started.
4. Developer Experience: DNA Unit Testing with Rust HDK
Here’s a little-known fact — you can write unit tests for your zome code, compile your DNA in test mode, and run the tests without firing up the full development conductor. Without this pull request, you would have had to add empty function definitions for all HDK API functions yourself in order to not get “unresolved references” when trying to run `cargo test`.
This change does add stubs for every HDK API function so that you can write unit tests for your zome functions that depend on the API. It’s pretty limited; your tests shouldn’t expect real responses from Holochain API calls, such as `commit_entry()` and `get_entry()`. Return values will always be a success with an empty payload!
5. Breaking Change/API Feature: CRUD Validation
You can now specify validation rules for removing or updating an entry. This comes with a breaking change: validation functions will receive only one argument, an enum called `hdk::EntryValidation<T>`, when this feature lands with 0.0.8-alpha. The generic parameter ‘T’ represents your entry types’ struct. The enum comes in three flavors:
- `Create`, which holds the new entry.
- `Modify`, which holds the old and new entries, as well as the old entry’s header.
- `Delete`, which holds the old entry and its header.
All three of these also contain the validation package. We’ll provide more documentation when this feature is available.
6. Challenges: Synching the Release Process and DevOps Support
We’re still in the process of adjusting to our new release process, and we’re grateful for your patience as we work out the kinks — lessons learned — follow the release script to the letter and watch out for those Windows test fails on the release candidate! Our goal is to have the weekly Dev Pulses sync up with weekly releases.
We’re also happy to report that we hired a DevOps Engineer last week and he hit the ground running. One of our devs commented that he’s already proven his worth.
He’s a whiz at tracking down build issues, missing or broken dependencies, and CI problems. He is helping immensely with consistent, high-quality releases.
