In this issue we share the story of how we got to 5000 (and now 7500) simultaneous nodes, what the claim actually means, why it matters, and what’s next. We’re also introducing a few hApps you can download and try today!

The last few weeks have seen working hApp code sprouting up like crocuses. More developers are adding their hApps to the index for others to try out, and they’re sharing open-source code modules to kickstart the development of new hApps. This is due in part to the hard work of those who are cultivating the developer community, particularly during the recent DevCamp. We’re really excited to see this organic growth; it hints at a new season for Holochain on its way.


  • The story of 5000 (now 7500) nodes
  • First sprouts in the hApp nursery—try them out!
  • Holochain Core: bug fixes, more performance gains, and changes to come
  • Building a hApp? Join forces with other devs
  • DevCamp 6: Participants share their experience
  • Holo Hackathons: Spring Edition

The story of 5000 (now 7500) nodes

Back in July of last year we decided to hold ourselves publicly to an ambitious goal: in order to to be ready for Holo Alpha testing, Holochain would have to be fast enough to support 5000 nodes operating simultaneously on one network. It was especially ambitious because, at the time, we didn’t have a functioning network stack.

Now it’s the new year, and as you know we hit that target almost a month ago. Shortly afterwards, a regression was introduced that capped that at 1500 nodes in high-load situations, but after fixing that bug, we are now up to 7500 nodes!

Why 5000 nodes? What does it mean?

We chose that exact number because it’s larger than the total number of HoloPorts ordered so far. To be ready for alpha testing, a functional Holochain runtime should be able to support app networks consisting of all HoloPort owners and a generous number of native Holochain users with a realistic level of activity.

What does this mean in real terms? The ideal we’re shooting for is that the experience of using a Holochain app should be equal to or better than a traditional cloud app, while delivering all the advantages of a decentralised peer-to-peer network. Blockchain’s scalability is limited by intentional architectural choices, while Holochain is designed to scale with the number of users. Everyone brings their own processing power, plus a bit extra to keep the network alive. This means that, in theory, a Holochain app can scale infinitely to meet the needs of real humans—humans who want their apps to be nimble and responsive, so they can get on with their lives. Our goal is to prove that it’s true in practice.

The most important metric for quality of user experience is latency, or “why is this thing taking so long?” So in order to deliver on our goal to create a usable framework for P2P apps, we needed to prove that Holochain could stay responsive in realistic situations.

Using the Tryorama testing framework, we designed a test to answer the question, “can a network quickly reach consistency if 5000 people try to join all at once?” While this might not be a common occurrence, it does make a good baseline for measuring how Holochain handles a highly stressful situation. We reason that, if it can handle this, it should be quite capable of handling more typical situations.

Our next job is to create a collection of scenarios to measure how Holochain’s performance improves over time. Latency, hence subjective performance, comes from a number of factors, including:

  • efficiency of core and networking code
  • DHT size
  • neighbourhood size
  • number of active users
  • quantity and size of data being produced
  • hardware and network specs

Some of these factors are specific or relevant to a given app or scenario. That’s why we want to stress-test with real hApps and realistic scenarios as much as possible. As mentioned before, our stress-testing infrastructure is capable of testing any app that has a few Tryorama tests written against it. Our current focus is basic Holochain functionality (joining a network, publishing data, retrieving data, direct messages) under basic scenarios (always online, disconnect and reconnect, crashed conductor, etc). We’re also testing HoloFuel as part of our ‘final exam’ test plan that determines Holochain’s readiness for the Holo host Alpha testing.

How did we reach our goal?

When we fired up real networking for the first time, we found that it was difficult to reason about the interactions of an unbounded number of independent machines in an unreliable network such as the internet. After all the big bugs were out of the way, some data was still getting stuck, and we were having a hard time getting Holochain to scale past 10 nodes. We needed a global view of traffic, so we could identify exactly what was getting stuck, and where, and then form theories about why.

So we introduced sim1h, a P2P network simulator that held the entire DHT in a central database. That was replaced with sim2h, which handles gossip routing centrally but lets agent nodes hold shards of the DHT. These two tools let us identify the causes of a number of tricky problems that prevented the network from reaching consistency.

After the consistency issues were resolved, we saw rapid gains in performance as we identified and removed bottlenecks. Many of these were related to multithreading, so we’ve put a lot of attention on making Holochain use threads more efficiently. As we tackled these hot spots, we went from 10, to 100, to 1000, to 5000, to 7500 nodes fairly quickly.

Our plan is to incrementally replace pieces of sim2h with decentralised pieces from lib3h (our fully P2P networking solution) as they are built and proven to work. Eventually there will be very little of sim2h left at all, except perhaps as a proxy for those who are behind restrictive firewalls. But you’ll still be able to use it in your own test simulations.

First sprouts in the hApp nursery—try them out!

Holochain supporters are familiar with the question, “when will we actually get to play with real hApps?” Here’s a secret: you already can! Holoscape, a user-friendly Holochain desktop app, lets you install and run hApps without needing to be a system admin. It even comes with a basic app store, which already contains a few community-created hApps along with ones that our own team are creating. If you’d like to show your friends and family what a completely serverless, privacy-respecting application looks like, download Holoscape v0.0.7 and try out one of the five apps below.

Note: Because Holochain is meant for participatory experiences, these apps will be a lot more interesting if you try them with a group of friends at the same time. And keep in mind that both Holoscape and the apps we’ve shared are in various alpha or proof-of-concept stages. If you find issues, the project maintainers would probably love a bug report or pull request!

  • Basic Chat, a proof-of-concept chat app built by Holo developers

Holochain Core: bug fixes, more performance gains, and changes to come

We released Holochain v0.0.44-alpha3 early this week. This is not yet a ‘blessed’ release, which means it isn’t yet available through the installation route (although we expect it to be blessed soon). In the meantime you can still download the binary packages and test out the release.

Here’s the summary:

  • Bugfix: Gossip no longer dropped in heavy load situations! This lets us support 5000 nodes and beyond. #2137
  • Bugfix: Improvements to reliability when joining network #2115 #2120
  • Bugfix: Better DHT lookups in offline mode #2119
  • Breaking change: Link queries no longer support regex matching #2133
  • Known issue: We’re still seeing direct message timeouts and investigating whether it’s related to Holochain or a specific hApp.

We’d especially like your feedback on the breaking change. We removed regex filtering of links because we were concerned that an attacker could craft a regex that overwhelms the DHT node that holds the links, causing performance issues and denial of service. If you’ve been relying on regexes to filter links on the DHT side, please let us know in this forum thread. We want feedback on how you’ve been using link tags so we can come up with useful link filtering tools.

Work on the new WebAssembly engine is progressing nicely. We’ve begun to connect it to Holochain core data flows and run vey simple DNAs. Once it’s fully integrated, we expect it to help in two ways:

  • Faster DNA execution: wasmi, the WebAssembly engine we use right now, is an interpreter. The new engine, wasmer, compiles WebAssembly bytecode to machine code. This means DNA code will run at near-native speeds. We’re not at a point where we can measure improvements yet, but benchmarks from the wasmer project show that it typically executes code 100 times faster than wasmi.
  • Better memory handling: As real hApps are being built, developers are hitting limits in the memory handling code in our current WebAssembly code. The code to support the new engine supports function inputs of several gigabytes.

Building a hApp? Join forces with other devs

We’ve seen a lot of developers starting work on new hApps recently. It can be difficult to know how to get started, though, especially because the ecosystem is still fairly young. There aren’t a lot of third-party libraries available to get you started yet, and a lot of people need the same functionality and are considering building it themselves.

We’ve created a new forum category, New Projects, for everyone getting started. We encourage new and seasoned hApp developers to get involved, team up with others, and find opportunities to work together on shared functionality. We also invite you to take this survey—not only will it help us understand how to best support you with future resources, but we’ll also reach out and help you connect with other developers in the community.

DevCamp 6: Participants share their experience

We’d like to share some feedback that a participant in the last DevCamp shared with us:

This devcamp was a really great experience for me and I learned a lot.

It was really helpful to have the entire group of people learn about Holochain at the same time. There were many questions from very different perspectives so I was learning much faster. And what’s more important, in much more depth, because I haven’t thought about lots of stuff that other participants were asking about. I now have a clear understanding of Holochain use-cases in development and app architecture specifics.

As a remote worker, I enjoyed regular video calls and socialization during the camp. Live coding sessions were just great. And I really appreciated twinkles as a neat way of communicating positive emotions while avoiding sound interruptions during the calls. Such a nice idea!

Development of a learning app during the devcamp was a great help in starting to write my own. I was able to do the homework for the app we were developing, and then switch to do similar parts in my app using this new knowledge. During the camp I was able to plan the architecture, define the data model, write some backend logic and tests for it. Of course, I still have a lot to cover outside of the devcamp scope, but it will be so much easier to keep going now that I have this base.


Holo Community Hackathons: Spring Edition

We have two hackathons coming up in North America this month!

  • Portland, March 13th–15th. Get ticket here. This was going to be hosted in Seattle but was moved at the last minute due to COVID-19.
  • NYC, March 27th–29th. Get ticket here

Development Status


Blessed (available via

  • Holonix: 0.0.62
  • Holochain Core: 0.0.42-alpha