Wind Tunnel gets reports, automation, multiple conductors

All the hard work put into Wind Tunnel, our scale testing suite, is starting to become visible! We’re now collecting metrics from both the host OS and Holochain, in addition to the scenario metrics we’d already been collecting (where zome call time and arbitrary scenario-defined metrics could be measured). We’re also running scenarios on an automated schedule and generating reports from them. Our ultimate goals are to be able to:

  • monitor releases for performance improvements and regressions,
  • identify bottlenecks for improvement, and
  • turn report data into release-specific information you can use and act upon in your app development process.

Finally, Wind Tunnel is getting the ability to select a specific version of Holochain right from the test scenario, which will be useful for running tests on a network with a mix of different conductors. It also saves us some dev ops headaches, because the right version for a test can be downloaded automatically as needed.

Holochain 0.6: roughly two (ideal) weeks remaining

Our current estimates predict that Holochain 0.6’s first release will take about two team-weeks to complete. Some of the dev team is focused on Wind Tunnel and other tasks, so this may not mean two calendar weeks, but it’s getting closer. To recap what we’ve shared in past Dev Pulses, 0.6 will focus on:

  • Warrants — reporting validation failures to agent activity authorities, who collect and supply these warrants to anyone who asks for them. As soon as an agent sees and validates a warrant, they retain it and block the bad agent, even if they aren’t responsible for validating the agent’s data. If the warrant itself is invalid (that is, the warranted data is valid), the authority issuing the warrant will be blocked. Currently warrants are only sent in response to a get_agent_activity query; in the future, they’ll be sent in response to other DHT queries too.
  • Blocking — the kitsune2 networking layer will allow communication with remote agents to be blocked, and the Holochain layer will use this to block agents after a warrant against them is discovered.
  • Performance improvements — working with Unyt, we’ve discovered some performance issues with must_get_agent_activity and get_agent_activity which we’re working on improving.

Open-source Holo Edge Node

You have probably already seen the recent announcements from Holochain and Holo (or the livestream), but if not, here’s the news from the org: Holo is open-sourcing its always-on node software in an OCI-compliant container called Edge Node.

This is going to do a couple things for hApp developers:

  • make it easier to spin up always-on nodes to provide data availability and redundancy for your hApp networks,
  • provide a base dockerfile for devs to add other services to — maybe an SMS, email, payment, or HTTP gateway for your hApp, and
  • allow more hosts to set up nodes, because Docker is a familiar distribution format

I think this new release connects Holo back to its roots — the decentralised, open-source values that gave birth to it — and we hope that’ll mean more innovation in the software that powers the Holo network. HoloPort owners will need to be handy with the command line, but a recent survey found that almost four fifths of them already are.

So if you want to get involved, either to bootstrap your own infrastructure or support other hApp creators and users, here’s what you can do:

Next Dev Office Hours: 15 Oct 2025

Join us on the DEV.HC Discord at 16:00 UTC for the next Dev Office Hours call — bring your ideas, questions, projects, bugs, and hApp development challenges to the dev team, where we’ll do our best to respond to them. See you there!