Summary

With a Holochain RSM-powered hApp coming to HoloPort testers within weeks, and hosting infrastructure being deployed soon afterwards, I thought it’d be helpful to explain just what it is we’re about to release to the world.

The Holochain core dev team has also released one more maintenance version of Holochain Redux (the old codebase). I’ll explain why we’re bothering to do this in spite of the fact that Holochain RSM is fast approaching usable status.

Highlights

  • Holo hosting infrastructure: “nothing special”
  • Holochain-Redux v0.0.52-alpha2 released

Holo hosting infrastructure: “nothing special”

There are a lot of moving parts in any web-based application: back-end application server, HTTP server, database, a few microservices, UI, proxy, and more. Most of the time these are off-the-shelf components that a dev team can assemble into a well-tested stack without too much trouble.

But when you’re the one building the stack, and it’s an entirely new stack because you want to bridge the traditional web to a new decentralised web, your task is a bit more demanding. Not only are you trying to make it feel comfortable to web developers and end-users, but you’re also exploring uncharted territory at the same time. There are unique challenges to face and debug, because the modern web wasn’t built for decentralisation. Standard components won’t serve you well; you end up having to invent a lot of new techniques as you go.

But if you’ve done right, it will seem like “nothing special”. Those two words jumped out at me when I was interviewing Alastair, Holo Hosting product owner, for this Dev Pulse. What he meant was that, to a user, a Holo-hosted web app feels just like any traditional web app built on centralised infrastructure. You see, distributed apps suffer from a usability problem (browser plugins? private keys? 24-word recovery mnemonics? and should I buy a Trezor? what the heck does a ‘Trezor’ do anyway?) and that’s why we’re building Holo. We want dApps to be “nothing special”.

Check out this video of someone ‘signing up’ for a Holo ‘account’ so they can use HoloFuel (I assure you this isn’t just a mockup). Looks pretty normal, doesn’t it?

Folks eager for results have asked us why there’s so little progress they can actually touch. I can appreciate the anxiety; we talk a lot about what we’re doing but aren’t showing much yet. The proof of the pudding is in the eating, as they say, and you can’t eat a pudding if you don’t have a spoon. In this painfully strained metaphor, the spoon is the upcoming ‘Hosted hApps Release’ for HoloPorts. This will allow HoloPort owners to not just use Holochain apps themselves, but to serve them up to regular web users, all hot and nutmeg-scented. (Forgive me; we just had Thanksgiving here in Canada.) This will demonstrate all the invisible ingredients we’ve been assembling over the past year.

Here are the ingredients as they currently exist in our internal QA testnet:

Each HoloPort stands at the interface between a peer-to-peer Holochain network on the left and the Holo hosting infrastructure on the right. The right-hand side stuff is what connects a traditional web user to the network of HoloPorts serving the app they want to use. Here’s a glossary of the terms I’ve used:

  • Matchmaking service: The centralised server that requests uptime and performance data from hosts and uses them to make decisions about which user should be paired with which host.
  • Holo resolver service: The centralised web API that receives web users’ requests to be paired with a host, then asks the matchmaker service to choose a list of suitable hosts for them. Once the user has created an account and received confirmation that the assigned host is indeed hosting an instance of the app for them, the resolver service also registers the host as their official host so they can be reconnected next time they log in.
  • Holo router service: The centralised proxy that forwards traffic between a web user and their assigned port. This service connects to hosts via a peer-to-peer VPN that allows them to punch through restrictive firewalls. It can’t see the contents of user traffic, because it’s all end-to-end encrypted. (For those of you who work in IT, the TLS connection terminates at the host, not the proxy.)
  • Chaperone: The protected iframe in the user’s browser that generates their key pair, talks to the resolver service, and sets up a secure tunnel to their assigned host’s Envoy service. It’s also responsible for a lot of the UX, such as sign-up, sign-in, and handling Holo-related failures.
  • Envoy: A server on the host that presents an HTTP/WebSocket interface for the conductor. It allows the Chaperone in the user’s browser to ask the host to provision an app instance and communicate with it (app API calls). It also asks the Chaperone to sign any data that the host intends to write to their source chain (‘wormhole’ signing requests).

In a previous Dev Pulse I explained how all these components work. All of what you see above is deployed and currently working, and working quite decently. So why haven’t we rolled it out to pre-release testers? Because the left-hand side is based on Holochain Redux, and as you may know, it’s slow. Depending on the length of people’s histories, Test Fuel transactions are taking from a few seconds to a few minutes to clear. (Bitcoin takes more than 60× longer, but we’re aiming our sights way higher than Bitcoin.) We don’t think this is a good user experience, even for those who’ve signed up for alpha testing and are ready for some rough edges.

Still, we learned a huge amount with Redux—both testing self-hosted HoloFuel with our pre-release volunteers, and testing the hosting infrastructure internally. It’s allowed us to find and squash bugs in the right-hand side, explore incompletely mapped design territory (including the UX of failures), and collect learnings for an upcoming refactor of HoloFuel.

The nice thing about the way the Holo team has architected this is that there’s a very clean separation of concerns between Holo and Holochain. They’ll be able to replace Redux with RSM fairly cleanly; there are very few Redux-specific assumptions baked into the Envoy HTTP server.

The exciting thing for me is that, once this release rolls out to HoloPorts, we’ll have deployed a fully functioning and permanent Holo testnet (albeit one private to testers)! That’s right; when folks on Twitter say “when testnet”, you’ll be able to tell them “right now, my friend.”

Rather than going live with HoloFuel as anticipated, both the self-hosted and hosted hApps releases will go live with an ‘elemental chat’ hApp, a collaboration between the Holo hosting dev team and Philip Beadle. That’s because part of HoloFuel’s refactor involves not just porting to RSM but also a simplification and optimisation for its primary use case—always-on hosting devices. We want to take the time to make it right. And we think you might have a lot more fun chatting with people than sending them fake internet money. 😉

I want to clarify that ‘fully functioning’ does not mean ‘feature complete’. Many components are still in development and will gain more features as time goes on. For instance, the matchmaking service doesn’t collect any performance information on hosts; it simply gives a random selection of host IPs to each web user. And the business services to support publishers and hosts are still being designed and coded. But, like a pumpkin pie without the whipped cream, what we have is already pretty tasty looking to me.

Holochain-Redux v0.0.52-alpha2 released

This will likely be the last release of Holochain Redux. This maintenance release fixes a few more consistency errors plus a memory leak, as well as adding a few features necessary for Holo hosting. As we want to focus on RSM and Holo Host, we probably won’t be blessing it, but you can get it by using this slightly longer installation command for Holonix:

nix-shell 
https://github.com/holochain/holonix/archive/release-0.0.85.tar.gz

So why are we cutting another release, when Holochain RSM is just around the corner? Mostly it’s to support internal testing of the Holo hosting infrastructure while we wait for the necessary features (such as the networking transport layer) to arrive in RSM. But we thought it’d be useful to you as well, if you’re blocked by the bugs below and are holding off on RSM until we start releasing binaries.

Summary for Holochain Redux v0.0.52-alpha2

  • Fixed memory leak in various timeout conditions of direct messages #2208
  • Fixed holding-list/CAS mismatch potential in various error conditions when sim2h requests aspect holding #2208
  • Fixed bug in holding remove link before add-link validation complete #2208
  • Added get_meta to admin interface for access to DHT info #2207
  • Sim2h messages now ssl encoded for security and simplify integrity so conductor only needs to sign JOIN message #2203
  • Adds conductor signing-service error #2203

So, did this help shine a light on things?

Holo Hosting can seem like a complicated black box. I hope this deep-ish dive into how all the pieces fit together, and how they relate to Holochain, has helped you understand what things will look like when we launch the hosting alpha testnet soon. If you have more questions, reach out to me on Twitter or jump into the Holochain Forum!

Development status

Latest

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

  • Holonix: 0.0.81
  • Holochain Core: 0.0.51-alpha1
  • hc-happ-scaffold: 0.1.2
Install Holochain Learn about Holochain Join the Discussion