Summary

Developer preview release 0.0.3 is out now! It brings together all the features we’ve been talking about for the last few weeks, plus expanded documentation, and a smoother install process. This release includes some crucial features, including a fully sync P2P network, a simplified Rust HDK, CRUD (update/delete entries), and app-to-app bridging.

Highlights

  1. Developer Preview 0.0.3 is Released!
  2. P2P Networking Has Arrived
  3. Improved Zome Scaffolding: Get Started Writing Tests Faster
  4. Smoother Install Process: Better Dependency Setup
  5. Holochain 101: How To Configure Debug Logging
  6. Stack Overflow: Ask Your Holochain Questions
the weekly pulse

Details

1. Developer Preview 0.0.3 is Released!

developer release

A lot of fixes, improvements, and new features are involved in this new release. As with every Developer Preview, this release inches us closer to the fully realized application stack. This is still a developer preview, so the API will still change and grow in future releases.

Rust

2. Full Networking Has Arrived

One of the most exciting things to land is a fully sync P2P network. We’re calling it the ‘hack mode’ P2P network!

As previously mentioned, it’s not a final implementation, but it’s sufficient for using and testing actual applications. The networking module exists in a separate project called n3h, which you’ll need to install separately. Read the installation instructions for more details.

Limitations:

  • Sharding isn’t implemented, so it shouldn’t be used for large networks because all data is replicated to all nodes.
  • There is no bootstrap service or local mDNS peer discovery, so you need to specify at least one peer in your container config.
  • NAT traversal isn’t working, so you may need to use a VPN or configure your router.
Holochain’s security model depends on a network of peers who are elected to witness, validate, and store each other’s actions based on a set of shared rules.

This means that the design of our DHT is crucial, and needs to do things other DHTs can’t. We’re working on our own design called rrDHT that matches Holochain’s needs — expect details in the future!

3. Improved Zome Scaffolding: Get Started Writing Tests Faster

making Holochain development easier

We’re committed to making Holochain development easy. Therefore, we’ve been working on our scaffolding tool, that generates a lot of generic code for you, so you can focus on writing the things that matter. We’re adding test stub creation to the `hc generate` command, so you’ll be able to get started writing tests based on a real stub “MyEntry” type.

Some build errors were caused by missing package dependencies in the code that the Rust scaffolding tool created, so we’ve fixed those too.

4. Smoother Install Process: Better Dependency Setup

If you’ve been experiencing ‘dependency frustration’ trying to install Holochain, you’ll be pleased to know that we’ve resolved some of the issues.

Windows developers will notice the most improvement, but we’ve also address improvements of the install process for Unix and MacOS.

Now, Unix and MacOs developers have install scripts, and Windows developers no longer need to manually set environment variables for ZMQ.

5. Holochain 101: How To Configure Debug Logging

getting started

Debugging the complex interactions between UI sending zome function requests, and nodes sending and receiving messages, is really hard. Having lots of logged events helps because we can see what’s going on, but pretty soon there’s just too much to even see what’s relevant.

Enter logging rules and colorizing. The container randomly assigns a color to each of the instances it’s running, making it easier to see the originating point of the messages.

The container also evaluates the log rules to determine which messages to display. The rules consist of a set of regular expressions that match everything that could get logged and either include or exclude it, as well as set the logged item’s color (optional). Because all our logging messages have a prefix to indicate the log message class and code area, you can exclude or include whole classes of logging messages at a time. For example, here’s the current default rule set:

[logger]
type = “debug”
[[logger.rules.rules]]
pattern = “^err/”
color = “red”
[[logger.rules.rules]]
pattern = “^debug/dna”
color = “white”
[[logger.rules.rules]]
pattern = “.*”

This is a generous configuration. It displays any logged errors in red, debug messages that come from the DNA itself (i.e. calls to debug from within the zome) in white, and everything else in the default color (because the “.*” matching rule doesn’t specify a color). This means that the color is assigned to the instance that logged the message.

This is mostly important for Holochain core developers because it lets us see what’s going on inside the code. Additionally, at this alpha stage of the game, it will certainly be helpful for DNA developers because it will help you see what happens in interactions between your nodes during testing (i.e. you’ll be able to see when validation fails, etc.). Happy logging!

Building with Holochain? We want to hear from you!

Are you building with Holochain? We would love to connect and hear more about your app/platform. Please, take a few moments to fill out this survey! Our goal is to list all the projects building on Holochain on our forum.