In the wake of our HoloPort Alpha Program announcement, I’d like to take a look at the guts of our HoloPort Alpha Program — specifically the separate networks and why they matter.

[ UPDATE: If you're a HoloPort owner, here are the official instructions for becoming part of the HoloPort Alpha Program. ]

(Also, this is the hundredth Dev Pulse! An exciting milestone! 🎉 Huge thanks to Amanda, Micah, Klaye, Paulii, Jarod, Lucas, Mary, the dev teams, and all the other people who’ve ever worked on it.)

The Holo network: actually three separate networks

The Holo hosting dev team will assign all hosts in the HoloPort Alpha Program to one of three networks:

  • The alphaNet is an alpha release of the production-ready Holo network. From the HPOS to the centralised infrastructure, it runs on code that’s known to be stable — appropriate for production use, though not necessarily performant, feature-complete, or bug-free. It sees a slow update cycle, only incorporating changes as they’re proven to work right.
  • The flexNet runs on code that includes features and bugfixes that want to be promoted to the alphaNet but need pre-release testing. This will be a mixture of stable and unproven components that will eventually make it into the release once they’re considered reliable. Components could come from the alphaNet, the devNet, or a special branch of the codebase that focuses on just one feature.
  • The devNet tracks the current state of development and is very unstable. This is where the daily work shows up, and is only used and tested by Holo team members. Automated tests are run on the devNet each night on new features and bugfixes, as well as to catch ‘regressions’ — previously working features that have been broken by new code.

The networks are almost completely separate, from web browser to HoloPort. All the centralised components — the web server that serves up the Chaperone script to the user, the matchmaker service that finds the user a HoloPort to connect to, the Holo router that connects the user to their chosen HoloPort, and the proxy and bootstrap services that connect HoloPorts to each other — are replicated so they isolate the alphaNet from the devNet. This keeps bugs from leaking out into the experience of users on the alphaNet, and it prevents resource-heavy automated tests from slowing the alphaNet down.

The Holo devs are describing this as a huge improvement in their ability to test changes — not only does it contain bugs, but it also vastly simplifies our testing and deployment setup. Each network can be deployed automatically — from the HoloPort, through the centralised infrastructure, to the scripts that run in the user’s browser. These are the kinds of quality assurance upgrades we need right now as we prepare for public alpha testing.

Explaining the requirements for the HoloPort Alpha Program

Remote SSH enabled

Because the Holo hosting dev team will be the ones choosing how many HoloPorts they need for each network, SSH will be enabled by default on all HoloPorts for this stage of the program. This is a big departure from our previous approach, so I want to clarify three things:

  • This is only for the duration of the HoloPort Alpha Program.
  • We’ll only be using it to switch your HoloPort between networks and perform support diagnostics.
  • In the future, you’ll be able to turn SSH off any time you like from the Host Console Settings. If you disable it, your HoloPort will not be used in the program — that is, it won’t be serving hApps to users, and you won’t be eligible to receive HoloFuel.

95% uptime

In the future, web users’ source chains will be backed up by multiple HoloPorts with an uptime of at least 90%. We’re aiming for 5× redundancy, which will give a total uptime of 99.999%, allowing users to access their app even in the unlikely event that four of their assigned HoloPorts are offline.

For now, though, each web user only gets assigned to one HoloPort. If it happens to go offline, all the users it’s serving can no longer access their app. That’s why the HoloPort Alpha Program requires 95% uptime as one of its eligibility criteria. This will be adequate for testing purposes; anything less will give an unpleasant user experience. We think this is worth paying for, which is why you’ll be getting a stipend in HoloFuel if you join the program.

If you’re eager to get involved, head over to the Holo forum and watch for announcements in the coming weeks.

An invitation: help improve the developer documentation!

The folks at Sprillow, a Holochain dev shop that focuses on good user experience (you should check out their Acorn hApp), also care a lot about developer experience too. They’ve invited everybody with some technical background to join their 24-hour Documentation Drive, starting today at 12:00 UTC (sorry for the late notice). You don’t need to be a Holochain expert yourself; you just need to be willing to dig a little and improve things just a bit.

It’s no great secret among hApp developers that the learning journey is a bit rough and wild; there’s a lot that could be improved. And the success of the Holochain ecosystem will rest on hApp developers, so this is a low-commitment, high-impact way to help out!

Join the documentation effort by filling out this form.

Thanks, Sprillow, for organising this!

Dev Camp update: 1000 registrants!

We’ve been floored by the level of interest in the upcoming Holochain Dev Camp. That’s a 4× increase over last Dev Camp; interest is accelerating!

If you haven’t signed up yet, here’s the registration form.

Breaking changes in develop: decryption function and must_get

If you’re developing your hApp against the develop branch of Holochain, two new breaking changes have landed.

  • One decryption function, x_25519_x_salsa20_poly1305_decrypt, had its parameters mistakenly reversed behind the scenes. The fix isn’t actually a breaking change; the host function signature and parameter order haven't changed. But if you discovered that you had to swap sender and recipient in order for it to work, you’ll need to swap them back to what the documentation says.
  • All DHT retrieval functions have been disabled in validation callbacks and replaced with new deterministic ones. If your validation callbacks need to load dependencies from the DHT, use the new must_get_* host functions to protect validation from sources of non-determinism. These functions are guaranteed to retrieve something; if there's something wrong with the dependency, they'll short-circuit in the host with the proper error.

Cover photo by Paul Carmona on Unsplash

Install Holochain Learn about Holochain Join the Discussion