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
- Developer Preview 0.0.3 is Released!
- P2P Networking Has Arrived
- Improved Zome Scaffolding: Get Started Writing Tests Faster
- Smoother Install Process: Better Dependency Setup
- Holochain 101: How To Configure Debug Logging
- Stack Overflow: Ask Your Holochain Questions
Details
1. Developer Preview 0.0.3 is Released!
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.
- P2P networking between machines
- Configuration format for containers
- Bridging now works and is configurable in the container
- Peer validators now receive supporting data from an entry’s author
- Update and delete entries
- Node-to-node messaging
- Get History on updated/deleted entries
- Get List of authors on entries and links
- Query source chain for multiple entry types
- Persistent source chain option for `hc` command-line tool
- Real networking option for `hc` command-line tool
- Groundwork for capabilities-based security and events/signals
- Improved debug logging with log rules and colors
- Rust HDK: Return native structs rather than having to convert to JSON
- Full Changelog
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
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
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!
