This is a very short Dev Pulse; I just want to cover the changes in this week’s Holochain release. (Note: there were no public 0.0.133 or 0.0.134 releases due to automation issues; these have been fixed (#1336, #1342).)

Breaking changes: HDK
Compatible HDK versions: 0.0.129

Links have gotten some more changes (#1298, #1308), bringing us closer to the Holochain Resource Locators milestone. Now you can use headers as your link base or target, without having to re-type them to entry hashes (which worked but felt kinda hacky to me). But not only that — you can now use external hashes as well! Hashes now come in one extra flavour, AnyLinkable, and all link manipulation functions now expect a new type called AnyLinkableHash, which can be converted from an entry, header, or external hash (note: the DNA hash is still not linkable, by design). That makes this a breaking change for the HDK. All you need to do for existing code, though, is put .into() at the end of an entry or agent hash value to convert it into AnyLinkableHash.

You can learn more about how Holochain uses and formats hashes by reading through the excellent HDK documentation update from two weeks ago.

Integrity/coordination split begins

The other change is that we’ve started to split the HDK in two. You’ll recall two Dev Pulses ago that one of our upcoming milestones is Stable Validation, which means that we are promising a stable core to the HDK so you can write stable hApps with stable DHTs. (See the pattern? Stability!)

This core, called Holochain Deterministic Integrity (HDI), is a subset of the current HDK’s functionality — only the types and host functions needed to define and validate data. In the future, zomes built with HDI will be the only zomes that contribute to the DNA’s hash, which will let you update business logic written with the less-stable full HDK without causing a network fork.

This release marks the beginning of the split. It moves all the features needed for deterministic integrity into two new crates — holochain_integrity_types for the types and  holochain_deterministic_integrity for the host functions (#1305, #1324). (In the process, the HDK no longer depends on rusqlite!) At this point, you don’t need to do any code edits, as these crates get imported into the HDK for you. But your zomes will need to be recompiled in order to be compatible with this week’s Holochain release.

Next up will be a way of specifying whether a zome is an integrity or coordination zome in your DNA manifest (#1325, likely to be in next week’s release). When this is introduced in a later release, you will likely need to split your code into integrity and coordination zomes. I promise I’ll write more about it when the changes solidify and make it into a release.

Various fixes and updates

  • The codebase is getting cleaned up with an eye to further stabilise the HDK. Types which require a membrane proof now require the SerializedBytes of the proof to be put into an Arc, so as to prevent the need to internally clone this potentially large amount of data. For instance, the AgentValidationPkg type now refers to the MembraneProof type, which is simply an alias for Option<SerializedBytes>. This change will require some minor refactoring if you’re using membrane proofs. (#1311)
  • Internal tests and compilation issues are being fixed (#1319, #1304).
  • WASM error messages now contain their line numbers for better debuggability (holochain-wasmer #81).
  • The admin API couldn’t install hApp bundles that were more than 16 MB in size; this is now fixed. (#1322)
  • Missing validation dependencies are now fetched asynchronously. (#1268)

That’s all for this week! Expect big changes in the next few weeks — as mentioned, though, these changes are intended to ultimately lighten your code maintenance burden, making DHT forks a rare event.

Cover photo by Bas van den Eijkhof on Unsplash

Install Holochain Learn about Holochain Join the Discussion