Summary
Holochain Developer Preview v0.0.4-alpha is now available for download! It brings the changes we’ve been promising — the name change from ‘Container’ to ‘Conductor’ (with renamed binaries), a massive documentation update, easier scenario testing, an important bugfix in core, and more.
Highlights
- Developer Preview 0.0.4-alpha Released!
- Traits: Logical Grouping of Zome Functions
- Important Bugfix in Core: Fixes Failing Zome Calls
- Simple-App Broken and Fixed Again
- Documentation for 0.0.4-alpha is Live!
- Signing, Signals, and Holo: Enabling Full Authority Over Data for Holo Users
Details
1. Developer Preview 0.0.4-alpha Released!
Highlights:
- Container/Conductor name change
- `holochain_container` binary renamed to `holochain`
- Holochain-NodeJS 0.4.1-alpha with easier scenario testing
- WASM memory model handles 32kb+ data
- Integrated crucial cryptographic code
Read the release announcement (with installation instructions) and the full changelog.
2. Traits: Logical Grouping of Zome Functions
In our quest to make Holochain more accessible to developers, we’re constantly assessing whether we’re using the right language. As you may know, we’re going to implement capability-based security for any agent under your control who wants to access one of your running app instances. However, we were using the term ‘capability’ to describe two separate things — both the aforementioned security model, and the actions that an app’s DNA is capable of performing. We’re now renaming the latter; they will be called ‘traits,’ which describes them well without creating confusion.
Capabilities and traits are related; you can expose an entire set of functions as a trait and then protect them with a single capability.
There is a default trait called ‘public’ that lets you define a set of zome functions that can be freely accessed by clients such as bridged DNA instances, UIs, and utilities. Other, more sensitive zome functions can be categorized in traits that require user authorization.
Trait definitions have now been moved to their own section of the `define_zome!` macro. You can see an example here.
3. Important Bugfix in Core: Fixes Failing Zome Calls
State management in Holochain-Core is a big deal. Lots of things are happening constantly in response to outside actions, so we’re very disciplined about reducing the side effects in our functions.
This lets us reason exactly what’s happening at every step of the process. For the curious, we’re using the ‘reducer’ pattern, which will be familiar to React or Haskell developers.
The portion of the core that deals with calling zome functions had some leftover concepts from when we were still exploring the approach. It was resulting in deadlocks that would cause tests and builds to intermittently fail. We’ve completely refactored this portion so that these failures have been completely eradicated. If you’ve run into this problem during app development, v0.0.4-alpha will be a welcome update!
4. Simple-App Broken and Fixed Again
We have a very basic app — Simple-App — that we use for testing node-to-node communication. Some devs in our community have tried it only to find that it gave errors. We’ve fixed that bug, so it’s usable now!
5. Documentation for 0.0.4-alpha is Live!
We’ve been hard at work expanding our Guidebook. You can now read about compiling zome code, testing your app, and using the Conductors.
6. Signing, Signals, and Holo: Enabling Full Authority Over Data for Holo Users
When we decided to build the Holo hosting ecosystem on Holochain, our goal was to give users power over their online identity and data. We wanted Holo-based participants to have the same rights as those who were running their own Holochain apps.
We were unwilling to compromise by holding their private credentials for them, signing data on their behalf, or controlling their accounts in any way.
It wasn’t easy. As a bridge between Holochain and the web, Holo is a mix of centralized and decentralized. It took us a while to figure out a process that would put users in full control of the key generation process, while offering a procedure that was as familiar as the traditional username/password form. The approach we have taken deserves a post of its own; watch our Holo Medium Account for an upcoming article!
In the alpha version of Holo, the user’s data will stay on the Holo host that’s serving them, but the user will also need to sign the data without sending their private key over the wire. Building on our recent work on Signals, every time a Holo host is about to commit an entry on behalf of a user, they notify the user’s browser through a secure connection. The user signs the entry and sends it back to the host over the same connection. The work has been completed on the Holochain side and is ready for incorporation into the Holo client library.
