I’m beginning to sound like a broken record, but the core dev team just keeps on developing Holochain RSM. New features have just landed, along with bug fixes and niceties for app devs. We’re closing in on our ‘leapfrog’ goal where we match Holochain Redux for functionality.

Various team members are testing HoloPort Nanos, and while the scope of testing is currently limited, everything looks good so far.

Meanwhile, the Holo Hosting team is working on porting the OS and critical hosting apps to Holochain RSM.


  • Holochain RSM updates: networking, bridging, and other stuff
  • HoloPort Nano testing update: good so far
  • HPOS and Holo hosting apps being ported to Holochain RSM

Holochain RSM (Alpha) updates: networking, bridging, and other stuff

Last week I was pleasantly surprised to discover how close Holochain RSM is to its ‘leapfrog’ goal: matching Holochain Redux for functionality (although I knew it’s already gone beyond in some ways, such as performance and correctness). In particular, networking is almost complete. Here are the details:

  • This is true peer-to-peer networking, without need for a centralised switchboard server.
  • Peer discovery over the public internet via a ‘bootstrap’ server is almost finished. Similar to the first Go-based version of Holochain, this server is meant to support high-quality peer discovery that’s resistant to ‘eclipse attacks’. But it’s also a centralisation point, so in the future hApp devs and end-users will be able to run and choose their own bootstrap servers.
  • Ongoing peer discovery, or gossiping new peers among those who’ve already joined the network, will be completed soon.
  • Peer communication over the public internet is supported through the use of proxy servers. These servers can’t decrypt gossip communications; the only thing they can see is the addresses of the sender and recipient. Anyone can run a proxy, but for now by default everyone will proxy through one server. This will make it easier to debug and test things in the near term.
  • Peer discovery and communication on your local network are not yet supported.
  • Neighbourhood sharding isn’t supported yet, and will be a focus of the next milestone.

Inter-zome calls (including bridging) has landed as well. This is the `call` host function that lets two zomes within a DNA, or two DNAs within one participant’s conductor, talk to each other. Bridges between DNAs no longer need to be configured at app installation time, which means that two DNAs can call each other if they like. This is a two-edged sword, best managed with care and discipline — it allows for more flexibility in your designs, but it also introduces the risk of infinite recursion. You can read some history on the topic in this forum thread from last year.

Note that bridge calls now respect Holochain’s capability-based access model. For calls between zomes in a single cell, or calls between cells instantiated by a single agent key, the implicit ‘author grant’ will cover it. But for calls between cells instantiated by different agent keys, the callee will have to create a grant for the caller first. (Note that the caller has to pass their capability token in both cases.)

You might also notice that `call` is a proper Rust function, not a macro. This is the first step of a plan to convert the entire host API to Rust functions; we hope this will help you by giving your IDE better code intel hints about input and output types.

Serialising and deserialising addresses (entry hashes, header hashes and agent IDs) is a bit simpler now; it’s just a vector of 39 bytes that gets serialised to a MessagePack byte array. This should make it easier to pass addresses back and forth between the DNA and the UI.

The conductor config file format has changed from TOML to YAML. We have a lot of hierarchical stuff in the config file format, and we think YAML will be easier to read and write.

I notice that functionality is getting integrated into Holochain RSM really quickly. There are two stories in my head about that: one, the simplified codebase is easy to work with; and two, we’re getting early feedback from app devs so that we can discover and fix both bugs and developer ergonomics issues early in the release cycle. This saves us from having to go back and revise a bunch of work further down the road, which in turn keeps velocity high. It’s a virtuous cycle.

HoloPort Nano testing update: good so far

HoloPort Nano test units are finally trickling through international shipping and customs pipelines into the waiting hands of team members. A few of us have turned ours on and conducted the first two tests: first, that they boot up, and second, that they update to the most recent version of HPOS, the HoloPort operating system, compiled for the Nano’s architecture. Both of these tests are passing in all cases.

HPOS and apps being ported to Holochain RSM (Alpha)

The Holo Hosting team continues to work on incorporating Holochain RSM into the HoloPorts’ operating system. The core hosting DNAs — Service Logger, Holo Hosting, and HoloFuel — are currently being migrated to RSM as well. In parallel, the Host Console and the Publisher Portal, which use the three core hosting DNAs under the hood, are still in active development.

The underlying operating system, NixOS, is also being upgraded from version 19.09 to version 20.09.

Here are some mockups for the Host Console that you’ll see when you log into your HoloPort. Many of these features are in development and won’t be available until a later release, but I like how they give a sense of what the hosting experience looks like.

Finally, we’ve got a small team working on implementing the HoloFuel reserve account. This involves a number of components, including UIs for HoloFuel purchasers and admins, interoperability between Holochain and Ethereum, and business rules for the management of the reserve account. Expect to hear more about the UX and security aspects of this important component of the Holo Hosting ecosystem as we continue to develop it.

Development status


Blessed (available via

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