Gosh, now that the dev team has moved to weekly releases, there’s a lot to catch up on when I skip a week! The most recent Holochain releases have a number of bug fixes that improve performance and reliability, along with a new feature (post_commit) and a few breaking changes.

Holochain 0.0.109: Gossip improvements

The release from three weeks ago brought some important bug fixes in the network layer, improving performance and reliability.

  • The conductor no longer tries to join networks that are already in the process of being joined. (#1006)
  • The genesis process no longer tries to self-validate ops that are produced for the first three source chain entries, which may require a network which isn’t available yet. Instead, a genesis_self_check callback can run against those ops as a reduced, network-disabled pre-validation. (#995)
  • Multi-peer gossip messages (e.g., publishing and retrieval of DHT data) no longer wait until timeout when enough responses have been received. (#1009)
  • Terminate a gossip round initiation if no responses are received. (#1014)
  • Don’t gossip with stale peers. This fixes a bug with long-lived DHTs, in which newcomers couldn’t see old data. The bug had previously been blocking a number of initiatives, including the Holochain Launcher and DevCamp. (#1014)

There have been some other speed improvements and fixes:

  • The conductor can now run 50 validations concurrently. This helps speed things up when some validations are slowed down waiting to retrieve DHT data. (#1005).
  • Commits to the source chain with the new ChainTopOrdering::Relaxed flag now store both header and entry; previously the entry was mistakenly being dropped.

Read the full changelog.

Holochain 0.0.110: More gossip improvements

The release from two weeks ago brought more networking bug fixes, which have made gossip even more reliable.

  • Agents now try to republish their authored source chain data until they receive the expected number of validation receipts. This helps ensure the data will stay available when the agent goes offline. (#1024)
  • Improvement to database write efficiency when storing information about peers. (#1007)
  • DHT requests are only sent to local agents if they’re authorities. This saves on internal chatter. (#1027)
  • ‘starts-with’ queries on link tags now work. This was working in the LMDB storage layer but not in the SQLite storage layer. (#1027)

Lair, the keystore for Holochain, is also undergoing a lot of changes. There’s been a lot of work to get Holochain ready for Lair’s new API (#1017), but your hApps won’t be affected by these changes. It does mean, though, that Lair and Holochain will be getting new features, including:

  • Seed bundle importing will allow you to use DeepKey to create an identity and one machine and connect it to your identity on another machine (Lair #70).
  • NaCl’s box encryption algorithm will be added to the HDK in addition to the existing secret box encryption (Lair #73).

If you manage conductor configs yourself, you’ll need to know that the Lair keystore config section has some breaking changes (#1031) as a result of the above.

Sweettest has also gotten some updates that make it more versatile (#1030). Not sure what Sweeettest is? Read on; I’ve written a bit about it after the next section.

Read the full changelog.

Holochain 0.0.112: Post-commit hook and DNA info

Last week’s release brings new developer-facing features and breaking changes. (Note that there is no official 0.0.111 because of a release automation issue.)

The biggest new feature is the post_commit hook. This lets you write a callback that’s called after every zome call that commits data. Your callback will receive a list of headers that have just been written, and can then do whatever it likes except commit new data. (#1000)
Read more about how to use post_commit in your hApp at the community wiki.

Breaking/new: Some info available via the zome_info host function -- the DNA ID, hash, and properties — have been split out into a new dna_info host function. This information is no longer available via zome_info, and the zome_name property has been renamed to name. (#1044) Additionally, a DNA’s zomes are now available via dna_info (#1052) and a zome’s entry type definitions are now available via zome_info (#1055).

Breaking: The structs HeaderHashes and HeaderHashedVec, which wrap vectors of other structs, have been removed. As this was only used in the previously unimplemented post_commit, it shouldn’t affect any of your existing code. (#1049)

New: call_info is partially implemented. A zome call can use this function to get info about how and why it was called. Currently it only gives the current source chain head, but in the future it will give information about capability context and how it was called (by a client, another zome or DNA, or a remote agent). (#1047)

Read the full changelog.

Sweettest: Rust-based Holochain testing

Sweettest is a Rust-based testing framework for Holochain apps. It has tools for creating conductors, loading hApps into them, and networking those conductors together. The Holochain dev team created it for testing Holochain and its various subsystems in different scenarios. And because it’s written in Rust, they can test everything from within one language ecosystem with simpler tools for automation and continuous integration. Besides the convenience of putting tests inline with code, they can reuse all of Holochain’s public-facing types like HDK and conductor API input/output structs. There’s no need to recreate a bunch of type definitions in TypeScript or depend on JavaScript client bindings.

Right now the Holochain team’s big focus is on testing sharding and scaling. They need rigorous sharding tests that ensure everything is successfully getting validated by the right DHT peers, no signals or messages are getting lost, and there are no bottlenecks. On top of sharding, they’re also testing how Holochain performs in large networks with lots of traffic, with an eye to analyzing what disruptions it’s encountering when it does struggle. This will become very important in the near future, because we’re just about to open up public access to hosted apps like Elemental Chat. If we can gather good data that pinpoints the source of problems, that helps us find solutions quickly.

From what I understand, they use Sweettest to run both small-scale unit tests and large-scale integration tests. Because Holochain is a framework for peer-to-peer computing, it becomes important to test the same chunk of code in multiple contexts, such as on different machines as they interact with each other.

Although its primary usage right now is testing Holochain, Sweettest can also be used as an alternative to Tryorama for testing hApps. That’s because the Holochain conductor is basically a runtime for hApps — much of the functionality can’t be tested without an actual hApp to plug into it. In fact, a lot of our Sweettest tests are built around hApp functionality.

Tryorama, the Node.JS-based Holochain scenario testing suite, is still our ‘official’ way of creating scenario tests for developers to test their hApps. But if you want to try something different — and don’t mind a bit of do-it-yourself — Sweettest might be worth a try.

All of our examples are specific to testing Holochain, of course, and some of them use zomes generated on the fly rather than compiled into a DNA. But they do show how to construct multi-conductor scenarios and test time-to-consistency, and even test a hApp. Hopefully they’ll give you a decent idea of how to create your own scenario tests.

DevCamp 8

How it started:                How it’s going:

😃😃😃😃😃😃😃😃😃😃😃        👩‍🏫🤯😤😊😎🤔🤓💪👍👨‍💻👩‍💻

Seriously, the level of excitement, thoughtfulness, and engagement has been wonderful to watch — and it’s remained high through the first three weeks of DevCamp and this week’s ‘reading break’.

Holochain In Action: Mapping important modules

The most recent Holochain in Action session explores the current landscape of modules you can use in your hApps already, along with the unknown territory at the edge of the map. Where are the gaps? What modules do we need to build next? How can we make sure we create things that will compose together well? (This is an important subject; composable modules are easier to work with, which means that more people can build better apps. We’ve touched on this in our coverage of a previous HIA session.)

One thing I really loved about this session is that the participants used Acorn, a Holochain app, to do their mapping. You can see their excitement as they all connect to each other, peer-to-peer, and start working together. Hooray for dogfooding!

Cover photo by zhang kaiyv on Unsplash