Summary
Holochain v0.0.5-alpha and v0.0.6-alpha are now released! This marks the move to a regular release schedule. We think that weekly releases will have a big impact on the development velocity of Holo Hosting and hApps everywhere.
Highlights
- Process Improvement: Regular Release Schedule For Reliable Dependency Management
- Holochain 0.0.5-alpha and 0.0.6-alpha: Developer Preview Releases Available
- Data Integrity: In-App Signing Functions In Rust HDK
- Developer Friendliness: Four New HDK Convenience Functions
- Developer Friendliness: Quiet Down DHT Logging
- Security Prep: ‘Public’ Capability Token
- Developer Friendliness: Robust Error Handling In Scenario Tests
- Challenges and Lessons Learned: Untested Code Is Broken Code
Details
1. Process Improvement: Regular Release Schedule For Reliable Dependency Management
The biggest news this week is our move to weekly releases. This might not seem all that spectacular, especially if you’re not building on Holochain yet, but we’re excited about this change. Here’s why:
- It unblocks hApp development. As we mentioned in last week’s Dev Pulse and Emerging Clouds, Holochain is Dependency Zero. The developers of HoloFuel, Holo Hosting, and Service Logs apps, as well as our internally created hApps, need to ‘pin’ their work to a relatively stable release of Holochain so they can be sure their features will work. Things are moving extremely fast within all teams right now — app developers will make a request or report a bug and the core team responds rapidly. Having a quicker release cycle means that updates make it into the developers’ hands more rapidly.
- You can start using new features right away. In previous Dev Pulses, we reported on upcoming features and bug fixes, as well as on our releases. It was tough to figure out what had landed and what was only available in the unstable `develop` branch. Now, when you read about something in the Dev Pulse, you’ll know it’s available in the latest release binary.
- The build process is streamlined and well documented. We’ve solidified our process for creating a release. This will improve consistency and reliability, and increase alignment with documentation and other projects.
2. Holochain 0.0.5-alpha and 0.0.6-alpha: Developer Preview Releases Available
Yes, we’ve published two new releases in the past week! Here’s what’s landed.
*There are more details on the most interesting items later in the Dev Pulse.
- New: Keys and signatures everywhere
- Breaking: New build script and compiled bundle file names
- Changed: UI JSON-RPC method to call Zome functions has changed!
- New: WASM panics in your hApp’s code now sent to the debug log
- New: Friendly error messages for missing dependencies
- Fixed: Link validation is resilient to propagation delays
- Fixed: Entry validation is resilient to propagation delays
- Changed: ZeroMQ replaced with WebSocket for communication with networking layer
- New: Throttle network debugging with environment variable HC_N3H_LOG_LEVEL
- New: `hdk::sign()` for in-app signing of data
- New: PUBLIC_TOKEN global variable in HDK for function calls
- Changed: Delete/update status propagated over network
- New: Four HDK shortcut utility functions that simplify link management
- Fixed: More robust error recovery in scenario tests
You can skip 0.0.5 — go ahead and download 0.0.6. Happy hacking! (Read the full change 0.0.5 and 0.0.6 changelog)
3. Data Integrity: In-App Signing Functions In Rust HDK
Even though Holochain has every participant sign every piece of data they produce, it’s still useful to be able to embed signatures right into the content of an entry. This is used heavily in HoloFuel, for example, to guarantee that each stage of the transaction process is countersigned. DeepKey also uses it to authorize and revoke keys.
The `hdk::api::sign()` function now exists in the Rust HDK. This will be followed by the complementary `hdk::api::verify_signature()` soon. Read the `hdk::api::sign()` API documentation.
*Breaking change warning: We may be modifying this function’s signature in the future to accommodate certain DeepKey needs.
4. Developer Friendliness: Four New HDK Convenience Functions
As regular readers may have noticed, we’re constantly looking for ways to make developers’ lives easier. We’ve just introduced four new functions to a new `hdk::utils` namespace; they should save you a couple keystrokes.
- `get_links_and_load_type()` automatically converts linked entries into the expected type.
- `get_as_type()` automatically converts the received entry into the expected type.
- `link_entries_bidir()` creates two links between two entries, one in each direction.
- `commit_and_link()` saves an entry and links it to another entry.
5. Developer Friendliness: Quiet Down DHT Logging
We recently implemented logging for n3h, the DHT library. A few developers, as well as our own internal dev teams, have observed that there is quite a lot of sifting output. This might be useful in some cases, but it can be overkill for general app debugging. Now, you can set the log level at runtime with the `HC_N3H_LOG_LEVEL` environment variable or in the production conductor’s config file. The possible values are the same in either case. Read the documentation for more info.
6. Security Prep: ‘Public’ Capability Token
As you may know, other things can call your app’s zome functions — GUIs, scripts, other clients through the Conductor JSON-RPC interface, and other DNA instances via bridging. Bridging only happens within the Conductor, and the JSON-RPC interface only listens for requests originating from the local machine, preventing attackers from the outside world from impersonating you. However, there is still the risk of locally running processes — trojans, for instance — trying to access your running instances without authorization.
We’re introducing capability-based security to protect this interface, as well as enable all sorts of interesting privilege models in Holochain. Anything that wishes to call your zome functions must have the authority to do so, in the form of a capability token.
Zome functions are exposed in ‘traits,’ which are logical groupings of functions that all share the same access level. There is one built-in trait, `hc_public`, that allows anonymous access. However, anonymous users will still need a capability token. The Rust HDK now exposes the public token via the global `hdk::PUBLIC_TOKEN`. Zome functions will need to use this token to call other zome functions in the same DNA.
If you’re curious about our plans for capabilities, you can read our design document.
7. Developer Friendliness: Robust Error Handling In Scenario Tests
Many developers who adopt automated testing say it allows them to make changes with confidence, knowing that if they break something, their test suite will let them know. But a test result is only as good as the test that created it (we’ll share some of our own stories in the next section). If you’ve spent any time writing tests, you’ll know that debugging the test itself is as important — and as tedious — as debugging the code that it tests.
We discovered an issue where tests with errors (syntax errors, uncaught exceptions, etc.) were hanging indefinitely rather than letting the errors bubble up. This was partially due to the fact that the NodeJS scenario testing library could accept both promise-based tests and raw functions. Now, it gracefully handles errors from both kinds of tests, allowing all errors to fail properly rather than leave you hanging.
8. Challenges and Lessons Learned: Untested Code Is Broken Code
Software development is a true craft, one in which you have constant opportunities to hone your skills. Few developers would ever say they’re “done” learning all there is to learn.
We’ve adopted automated testing as a crucial practice for ensuring that the quality of Holochain remains high as we add features and remove bugs — and sometimes the bugs are tricky, but these tests can be even trickier.
You may be certain that you’ve explored all the possible edge cases of a certain function, and all tests pass on your machine, but then fail during CI or real-world testing. You might make a small error in the test that makes it look like your code is buggy, but it was really the test error at fault.
That’s what was happening with a few of our tests recently. The design of Holochain-Core is deterministic and side-effect-free, as it simplifies reasoning about code and validation logic. However, Holochain is also meant to talk to a distributed network, which is full of non-deterministic behavior. This sometimes leads to end-to-end testing that fails one time and succeeds another.
The new ‘hold-for-validation’ code — which allows link validation to be paused until their base and targets have propagated through the DHT — was one area where we encountered this problem. Our solution was sound; it was passing tests, but the chief HoloFuel developer was getting test failures. We had to revisit the solution with a fresh pair of eyes (and an extra pair of eyes too), and that’s when we finally found and fixed the issue.
It highlights the need to be constantly sharpening your sight, slowing down, accepting input from others, and trying your solution again and again. We’re increasing our skills every day — it’s impossible not to in a project of this magnitude.
