Holochain Developer Preview Release
This new release marks a major milestone in the Holochain development cycle. I would like to take a moment to share more details about this developer preview release and actually make visible what we have been up to during the past few months.
After showing that Holochain works with our proof-of-concept prototype in Go, we started over in Rust just after the successful Holo ICO closed back in May. We had several reasons for this rewrite, despite getting very appreciative feedback for that Go code-base.
The main reason was to enable Holochain to be compiled to WebAssembly, and thus, enable Holochain light clients running in the browser (which is needed for the Holo hosting app) to use the same source code as the Holochain core. A previously discussed alternative was to rewrite parts of Holochain in JavaScript, but we saw how WebAssembly had progressed since we started working on Holochain, and it got us excited! Also, Rust comes with a lower run-time footprint than Go, and we think its rigorous compile-time checks and approach to memory management will put Holochain on a super-solid footing.
While the work on that old repository came to a hold 5 months ago, https://github.com/holochain/holochain-rust is buzzing with 118 merged pull-requests in the last month alone:
Yes, we, the Holochain core team, are all working on the Rust rebuild now and are proud to announce our developer preview pre-release of this brand new code-base.
This release is mainly targeted at developers to get early feedback for our new API. And yes, the API did change, and might change again according to feedback from you all. We gained several insights from watching people build apps with our prototype and want to continue learning more. Building working apps with Holochain Go is already much easier compared to other frameworks for decentralized apps, but we think we have a lot of improvements in the pipeline that help understand and express Holochain specific aspects even better.
A word of advisory, this release does come without a network stack!
“A framework for decentralized apps without a network stack?” — you may ask yourself. Yes, this is the main reason this release is called developer preview. In the Go version we took a few short-cuts to get to a proof-of-concept prototype. With this Rust rewrite, we are taking all long-term requirements into consideration - especially requirements of Holo. The networking code is not finished yet, but we also don’t want to postpone showing our new API for feedback.
What’s the state of the Go prototype?
In regard to the Go prototype, we are no longer working on it and don’t plan to allocate our resources to keep it up to date with breaking changes of Go dependencies. If you want to keep using it with your prototype apps and continue learning Holochain concepts, best stick to using the binary releases. The concepts you learned will remain, but upcoming versions will give you a much more robust and polished development toolbox.
So what is different? WebAssembly and HDKs
The Rust version of Holochain uses a WebAssembly interpreter for all Holochain DNA code, therefore, you could basically use any language that compiles to WASM to build your app. However, because WASM only knows about primitive types, passing strings and complex structs is something that needs boilerplate wrapper code. Holochain entries and the parameters you get in validation callbacks etc. are complex structs. To make it easy to create WASM based DNA code, we are creating frameworks that we call ‘HDKs’ — Holochain Development Kits. They are written in WASM-compatible languages that developers are familiar with, and they relieve developers from having to write their own memory management, serialization and other boilerplate code, as well as providing the Ribosome API in the language which the framework is written in.
Powerful macros
Our first official HDK is written in Rust. Using Rust’s powerful macros, we can define a much more concise domain-specific language (DSL) for Holochain specific aspects like entry types, entry validations and zome functions that will enable writing much more elaborate Holochain DNA code.
Let’s look at an example:
This define_zome! macro is basically like the main() function of a Zome — the building block of any Holochain DNA. This example defines an entry type Task with a simple validation function that just checks if the text is set, and two Zome-functions. Zome-functions constitute the interface of any Holochain DNA that can be used from the UI — think controller actions while entries are your domain models.
In the Go version this information was spread over several files and referenced from a JSON DNA file. We are still using JSON as the format for DNA files, but we introduced two major advantages:
1. Most of that JSON code is generated automatically from these macros
2. Our tooling comes with a packaging process that automatically compiles the DNA Rust code to WASM and integrates the binary output as a base64 encoded string in that DNA JSON file. The result is a fully self-contained DNA bundle in one file.
We also started working on an Assemblyscript variant of this HDK for a more JavaScript-like syntax. This is still experimental and not usable yet as we are waiting for some core features to be added to Assemblyscript. But the Assemblyscript community is very responsive to our needs and we’re looking forward to providing a full fledged HDK on top of it soon!
To summarize, the underlying API functions and callbacks will be binary and WASM based. But you will not have to use this low-level API since we’ll provide high-level DSLs in Rust now and Assemblyscript soon. But basically every language that compiles to WebAssembly can be used and more HDKs can be added to provide different styles and DSLs for building apps in the future.
Spec driven development
If you want a sneak preview of how to build apps on top of this HDK for the new Holochain Rust version, have a look at our spec repository: https://github.com/holochain/app-spec-rust.
This is an example app that is compiled and packaged into a Holochain DNA file. We use this repository as living spec and drive our further development from that point. Meaning, we create pull-requests there in which we describe features and new DSL syntax (by just using it) that is not implemented yet. These pull-requests serve as a space to discuss and consolidate new features, and then we build Holochain to meet that specification.
The Travis CI is configured to run those specs against the current head of the develop branch in https://github.com/holochain/holochain-rust. We do expect those branches to fail initially and until the new feature is implemented. At which point we merge the PR into master.
What this means for you is that the main branch in https://github.com/holochain/app-spec-rust shows an up-to date summary of what is possible with the current development version of Holochain Rust, at any point in time. Furthermore, if you have specific change requests that you want to see implemented in Holochain before we declare the API stable with the beta release, please go ahead and show us what you need by adding a pull-request there!
Hello “Containers”
Lastly, we have introduced a new entity into the architecture stack of Holochain: the Container.
The new Holochain-Rust code-base is a library. So you need another project that compiles to an executable in which the core API is used (and to which this library gets linked) to instantiate a Holochain node with a given DNA. You could totally include that library in your own app (say native Objective-C iOS app for instance) to “merely” use Holochain as your decentralized data integrity layer that replaces a central back-end.
However, we envision a rich ecosystem of many small micro-service style apps in the long run. For that to happen, app composability and a native application, a service running several apps in the same virtual space for the same user, like a Holochain browser, is an important architectural piece.
With this release we’ve created an MVP of such a Holochain app container, HoloSqape, that comes bundled with a generic UI that creates inputs and buttons for each Zome-function a DNA exposes.
This makes it possible to send your Holochain app DNA file to your friends and have them install and run that app in HoloSqape (or hcshell, the command-line version). The container stays running in the background with a system-tray icon. UIs could either be connected to your Zome-functions through a websocket connection or you could write QML based UIs that can be added to HoloSqape.
With all of this combined in our developer preview release, it is now possible to get a first impression of how to build Holochain apps with the new and refactored version, actually run those apps locally and even attach UIs. While we are working on the network stack and more sophisticated features like bridging, please go ahead and try out our new API. We would love to get your feedback!
Helpful Links:
Starting point should be our new (and still evolving) Holochain book: https://holochain.github.io/holochain-rust/
HDK (and core) code documentation: https://holochain.github.io/rust-api/0.0.1/hdk/
The Developer Preview release itself: https://GitHub.com/holochain/app-spec-rust/releases
Developer Preview Spec Repository: https://github.com/holochain/app-spec-rust
Holochain Rust Repository https://github.com/holochain/holochain-rust
Command-Line tool hc: https://github.com/holochain/holochain-cmd
HoloSqape and hcshell containers: https://github.com/holochain/holosqape
