Summary

HoloFuel keeps being tested, Pre-Release testers are having a lot of fun with it, and the dev teams keep squashing bugs. We’re also working on the Hosted hApps update for HoloPorts, which will allow hosts to serve HoloFuel to web users.

After publishing Holochain v0.0.51, we discovered a bug that causes multi-party scenario tests to fail. If you’re a hApp dev, you’ll want to read about what to do.

Lastly, I wanted to share a bit on our progress with the refactoring work that the core team has been doing. It’s pretty promising.

Highlights

• HoloFuel testing going great
• Hosted hApps Update in the works, also going great
• Holochain known issues: regression in hApp testing framework, consistency issue on disconnect
• Some early results from core refactoring progress

HoloFuel testing going great

Our group of Pre-Release Testers are having a lot of fun pushing HoloFuel to its limits, exchanging Test Fuel with each other and discovering edge cases for our dev team to fix. It’s been entertaining to see absolutely massive sums changing hands.

Our intention for this round of testing was to let things get chaotic, just to see if testers could discover bugs we hadn’t seen before. It was both fruitful and uneventful; while we did find bugs both critical and trivial, there weren’t many of them. Right now we’re fixing and testing these bugs with HoloFuel:

• issues in the conductor and HoloFuel DNA causing occasional transaction errors
• missing account icons
• account handles not updating on change
• decimal precision error in validation
• a collection of small UI changes

We hope to roll out the fixes to Pre-Release Testers next week. We’re looking forward to rolling it out to all HoloPort owners after that testing is complete. And then…

Hosted hApps update in the works, also going great

Beyond the above update and another update to make it easier for HoloPort owners to enable and disable remote SSH access for developer access, we’re also working on Hosted hApps. This’ll let HoloPort owners host hApps for other users.

That’s why you bought a HoloPort in the first place—a plug-and-play box for your own hApps is nice, but what you really want to do is earn money hosting hApps for others. Though there are a few other updates we’re prioritizing first, this release is also within view now and will be our first public test of that functionality.

So why is this different from what’s already being tested? The HoloFuel screenshots you’ve already seen show a HoloPort owner’s own app instance. The one above shows a web user creating a Holo account and using a hosted instance of HoloFuel on someone else’s machine. The user doesn’t know or care they’re using a Holo-hosted app; it just looks like a normal web app.

We’ve added some patches to Holochain to tighten end-to-end encryption, and now we’re working on robust handling of all the potential failure cases: user goes offline, host goes offline, no hosts are available for user, etc.

This is more complicated than the failure cases for a self-hosted hApp, where a HoloPort owner is guaranteed to have their own running instance as long as their device is turned on and connected to the internet. We have to consider the above scenarios from the user’s perspective, but we also have to consider what happens from the host’s perspective. This is because, with a Holo-hosted hApp, the user has complete control over their credentials. They’re generated in-browser from their email and password and never leave their device. That means that, for every piece of data a HoloPort stores on their behalf, it has to ask the user’s browser to sign that data. With our design, this happens asynchronously so a user may accidentally close their browser before their appointed host has had the chance to ask them to sign a particular piece of data.

It’ll be important to handle these cases in not just a technically correct way, but in a human-friendly way too. All Holo-hosted hApps will benefit from this work, and we’ll know we’ve done it right when end-users say they understand how to interact with these hApps even when things go wrong.

Holochain known issues: regression in hApp testing framework, consistency issue on disconnect

After releasing Holochain v0.0.51-alpha1 last week, we discovered an issue with Tryorama, the framework for testing multi-agent scenarios. The bugfix introduced into this version breaks the way Tryorama waits for the DHT to come to consistency, which means that your tests may fail. Head to the developers’ forum to find out how to work around this issue; we plan on retiring `s.consistency()` and introducing a new way to test for data propagation in the DHT.

We’ve also discovered a holding list discrepancy that can happen when a node publishes data in partially offline mode, then shuts down. A fix is being tested by the HoloFuel Pre-Release Testers this week and will be in an upcoming release.

Some early results from core refactoring progress

I’ve dropped a lot of hints in the past few months about how HoloFuel testing has pushed us to take a look at how we’ve architected Holochain’s core. So far I haven’t shared much in the way of actual details of the refactoring work, so I want to give you some encouraging news.

The big goals in this work are correctness, maintainability, and performance. I won’t share much about the correctness side of things, because correctness is simply correctness—it’s either there or it isn’t. But I will say that the simplified internals are making it much easier for the core devs to reason about whether the source chain and DHT actions are doing the right things, as well as to pinpoint the source of the problem when they aren’t. And maintainability is hard to talk about because it’s often intangible, more of a ‘felt’ thing.

Performance is easier to talk about because you can give figures. Keep in mind that these are early numbers and they might go up or down as we add functionality or shave off inefficiencies, but so far things are looking great:

• While the Holochain binary is still hovering around the same size (~15 MB), it’s handling memory much more efficiently, only bringing DNA code in when it’s time to make a call and only keeping it there if it’s frequently used. This’ll be great for everyone but crucial for the HoloPort Nano.
• Compiling a zome now takes a few seconds rather than minutes.
• Binary data such as photos can use 25% less space when being stored and transmitted.
• Zome and validation function calls now have <1ms overhead with wasmer, the new WebAssembly engine, a huge drop compared to wasmi. We also expect actual execution time for non-IO-bound function calls to drop by 100×.
• A running function now has access to the full 4 GB memory limit of the WASM runtime, whereas the current design caps out at about 100 KB. Along with the improved WASM performance, this could open the door to performing heavy tasks directly in the DNA, such as image processing and validation, distributed AI (think GPT on a DHT), homomorphic encryption, and zero-knowledge proofs.

(Note: In previous articles I’d mentioned that we were testing LMDB as a faster replacement for the storage back-end, but it turns out Holochain has had that since October. It looks like it only improved performance in one case, so I suspect that most of the improvements are coming from other areas.)

We’re also running performance regression tests on every large piece of work we integrate. These will alert us if any changes impact performance—we’re serious about keeping Holochain fast and lean.

We’re really excited by the results; they should put us in great shape to surpass our current performance stats as we integrate them into official releases of both core and related Holo hApps and continue our journey farther into Open Alpha.

Development status

Latest

• Holochain Core: 0.0.51-alpha1 (blessed) | Changelog
• Holonix: 0.0.81 (blessed) | Changelog
• Tryorama: 0.3.4 (blessed)
• hc-happ-scaffold: 0.1.0 (blessed) | Project
• Holoscape: 0.0.9-alpha (contains Holochain Core 0.0.47-alpha1) | Download

Blessed (available via https://holochain.love)

• Holonix: 0.0.81
• Holochain Core: 0.0.51-alpha1
• hc-happ-scaffold: 0.1.0