Yesterday we announced the HoloPort Alpha Program, where HoloPort owners can earn in HoloFuel just for leaving their machines on. (I’m not kidding! Go read the announcement! There are some uptime requirements, and it might not be available in all countries, but that’s about it.)
What is this program about? Haven’t we already been alpha testing the Holo network for ages? Well yes, that’s technically true. The difference here is the whole ‘paid in HoloFuel’ thing. And the reason for this is that we need a lot of HoloPorts to stay turned on all day. Here’s why.
Availability and scalability
As we start inviting people to test out Elemental Chat hosting via the web, we need to be assured that the HoloPorts assigned to store their messages will stay online. In the future we’ll have redundant backup for each user’s app instance, but for now our focus is more on stress-testing Holochain and the hosting infrastructure.
We also want to be able to serve lots of users and see how it performs. In order to do this, we’ll need to have lots of capacity online, ready to start serving apps to new sign-ups.
Our current pre-release alpha testers have been wonderful — infinitely patient, supportive, rigorous in their testing and bug reporting. But as we invite in more testers, we want it to be a smoother experience — both for their sakes, and for the sake of our support team.
So as the dev teams keep building features and fixing bugs in Holochain, HPOS (the operating system on HoloPorts), and Elemental chat, we need to roll the updates carefully so we can roll them back if needed. Hosts who choose to participate in the Alpha programme will allow their HoloPorts to be remotely switched to staging or various different testing channels of HPOS. These tests will remain small — restricted to team members and the aforementioned pre-release members. Hidden bugs will get discovered before they’re released to the wider world, which will make everyone happier.
Holochain v0.0.101 released
The core dev team has released a new version of Holochain this week. It comes with a huge pile of changes (v0.0.100 was released in February, after all, and the
develop branch has been changing fast since then). Here’s a short list:
- The storage engine has moved from LMDB to SQLite in preparation for sharded storage and the immune system.
- Network traffic for entry publishing has been throttled back to avoid flooding the network.
- The gossip algorithm no longer floods the network on each received operation, moving instead to a slow loop. It also uses Bloom filters rather than Merkle trees for syncing, which means brief CPU spikes but fewer bytes over the wire.
- Wasmer, the WebAssembly engine Holochain uses to run hApps, has been updated to version 2. We’ve discovered a bug in this version of Wasmer that causes memory leaks and slows down execution. We’ve built some workarounds, but we’re waiting for the bug to be fixed upstream. In the meantime, you should only notice performance issues if you’re testing lots of instances of a single hApp in one conductor.
- The admin API for installing apps has changed:
• There’s a new endpoint,
• The endpoint
RegisterDnacan now take a
• Breaking: The endpoint
InstallAppnow only accepts DNA hashes. Specifying DNAs by paths has been removed, as has the ability to specify properties at install time. Please move to using
• Breaking: When specifying DNAs by path, the endpoint
RegisterDnamust point to a DNA bundle, not a single DNA file.
- The dev tool
hchas had the
install_appsubcommand temporarily removed in favour of
- Breaking: All references to
”uuid”in the DNA have been renamed to
- The HDK has two new crypto functions,
Read the whole changelog here.
Performance warning: We do expect performance to be better in some places and worse in others. Changes in the wire protocol have resulted in less network traffic, while changes to Wasmer and SQLite have both improved and degraded memory and CPU usage. Using v0.0.101 for development work should be fine, but we don’t recommend bundling it with user-facing hApps yet.
Errata and additions for last week’s developer ecosystem roundup
After I published all those lovely developer resources, a couple devs pointed out that I’d missed some pretty important ones. There are also a few new things that have popped up in the meantime.
- Embedded Holochain Runner makes it easy to run Holochain as a library in your own app. This lets you bundle up everything in a single executable without any background services to manage. It’s already being used in Acorn.
- There’s the beginnings of a geolocation zome that lets you tag and search for things by latitude and longitude. The developers are also talking about adding the ability to search within range, optimised by breaking the globe up into ‘cells’.
- There’s a full set of TypeScript typedefs for Holochain core types; this is useful for interfacing your UI with your DNA.
- Connor Turland has written up a great guide on unit-testing zome functions and validation callbacks, along with a minimal example and some handy validation helpers.
- The community-created wiki is growing, with new articles on writing good validation functions, serialising Rust enums nicely, and creating a network.
- There’s a rich conversation happening on the forum about what the developer experience is like so far. If you’ve been doing any dev work with RSM, come over and celebrate/complain with other devs :)
Do you have any developer resources I’ve forgotten? Post them in the comments section below and I’ll feature them in a future Dev Pulse.