Summary
Our primary focus right now is preparing Holochain for the needs of Holo Closed Alpha. Holochain is Dependency Zero for all hApps, including the three hApps that will form the foundation of Holo Hosting. To that end, we’re closing bugs, building the features required by Holo, and improving the overall build process.
Highlights
- Learning to Dance: Holochain and Holo Progress
- Data Integrity: Moving Towards Consistent Validation
- Build Process Improvement: Removal of ZeroMQ
- Developer Features: Delete/Update Gossiping Over Network
- Leveraging the Right Skills: Challenges and Lessons Learned
- Holochain App/Platform Builders: Get Listed on our Website
Details
1. Learning to Dance: Holochain and Holo Progress
Holochain is the cornerstone of our work; it is the engine that powers the distributed Internet we’re trying to build. It powers the HoloFuel currency, the Holo Hosting and Service Log apps that allow hosts to manage their devices and get paid for their services, and all the hApps with which the world will soon fall in love — abandoning centralized services in droves. 😉
Because of this, many things in ‘Holo and hApps Land’ have had hard dependencies on Holochain itself. In turn, both Holochain and Holo have had soft dependencies on the core hApps. We’ve been moving rapidly, but even so, at times the Holo and hApps dev teams have had to wait for features to land or bugs to be fixed in Holochain, and vice versa. It’s been tricky to coordinate the movement between the three teams. We’ve definitely been forced to level up our dancing skills in order to unblock each other.
Some of the features needed for Holo Closed Alpha will be ‘scaffolded’ — we’re building something that will work temporarily, but will be replaced with a permanent solution in a future testing stage. As a consequence, we’ve needed to introduce temporary support into Holochain itself.
The journey has been a long one. We don’t think it could have unfolded much differently, because we’re venturing into uncharted territory. Many explorers set off with a goal or destination in mind, but they didn’t have a map to get them there — they were creating the map. There have been and will be excursions, some of which get scrapped — in software dev, we call those excursions ‘spikes.’ It’s necessary to go through this process, taking care to be thoughtful and challenge your assumptions at every step. As inefficient as it seems, this exploration of the problem space ultimately results in a stronger product.
Sometimes, you hit setbacks of another kind; they aren’t critical to your goals, but they still manage to block your passage. Bugs in third-party tools, team processes, hardware malfunctions, and the well-being of your team slow you down in ways you don’t anticipate.
These things make it very hard to estimate how long the journey will take. It’s doubtful that any great explorer would have said: “Destination arrived at in Q4 — home by Q1.” And their patron probably wouldn’t have believed them if they had. This is why we’re committed to providing regular updates, rather than hard, date-based promises. We feel this is much more appropriate and honest for a project like ours.
2. Data Integrity: Moving Towards More Consistent Validation
We encourage developers to think about deterministic validation — which means that given a certain data entry, a validator should always return the same result as any other validator. Nothing should be ambiguous regarding the correctness of a piece of data. This gets tricky when you’re working with a non-deterministic, ‘eventually consistent’ system, where each agent has their own view of the world and data propagates at varying speeds.
We were getting a lot of errors related to links during the testing of HoloFuel and other key hApps. Nodes would return an empty list when asked for links, even though the links were valid. (Note: This is not the same as a similar bug mentioned in Dev Pulse 12.) This was caused by a tricky issue — in order for a link to be valid, its base and target must both exist. But what happens when a validator receives a link before its base? This meant that link validation would sometimes succeed, and other times, fail.
Validators now hold links in a ‘pending’ state until they receive their base entry. This is the first step in a new approach to deterministic validation, and we’re considering making it possible for entries that depend on other entries as well.
This will allow developers to specify dependencies declaratively rather than having to fetch them from the DHT at validation time.
3. Build Process Improvement: Removal of ZeroMQ
One of the setbacks we encountered was the difficulty of incorporating ZeroMQ into the build process. ZeroMQ is a library for interprocess communication that we introduced because we wanted to separate the development of Holochain-Core from the networking layer, and needed a way for them to communicate. This allowed us to iterate on both without introducing too much friction. However, for all the friction it reduced, it also introduced new friction into the build and installation process — especially on Windows.
We’ve finally removed ZeroMQ from both Holochain-Core and the networking layer, opting instead for a local WebSocket connection. Rust and Node.JS — the platform on which we’re building the prototype networking layer — both have good support for WebSocket and it’s quite fast. This means that Windows builds now pass with flying colors!
4. Developer Features: Delete/Update Gossiping Over Network
We introduced CRUD back in Dev Pulse 08. It allows you to ‘delete’ and ‘modify’ data in the Holochain DHT, which is a database whose contents can’t be deleted or modified. Entries are instead marked ‘obsolete’ and include an optional pointer to the replacement version. At that point, CRUD metadata stayed on the local source chain. With this recent update, however, CRUD metadata is now gossiped to the DHT.
5. Leveraging the Right Skills: Challenges and Lessons Learned
We like to share our successes in these Dev Pulses, but we don’t share much about the challenges we face. We’ve always tried to do things differently and hold ourselves to a standard of transparency. We therefore believe it would be valuable to start sharing some of our ‘less-than-optimal’ experiences. Who knows? Maybe you’ll see yourself somewhere in our struggle.
They say, “The best time to plant a tree is ten years ago; the second best time is today.” It took us a very long time to acknowledge the importance of a dedicated DevOps person. All of our devs are incredibly talented; we all know how to dig into a problem and find a solution. However, spending time ‘yak shaving’ — focusing on a certain class of problems — is not leveraging wisely.
Our skills and passions lie in solving the problems central to Holochain, not in the auxiliary problems. Fighting a CI server, getting a third-party library to build, or doing QA on release binaries is not core to our offering, but it still needs to be done.
As we’ve shared in previous Dev Pulses, these issues, plus many other small, non-central issues, have slowed down developer velocity and caused lots of headaches.
So we’ve finally committed to hiring a DevOps Engineer and a Product Owner & Release Coordinator.
We wish we would’ve invested in these capacities a while ago — they will free our dev team to focus on the things at which they excel, while ensuring that all the production processes are taken care of swiftly and skilfully.
6. Building an App/Platform on Holochain? We want to hear from you!
Are you building on Holochain? We would love to connect and hear more about your app/platform. Please, take a few moments to fill out this survey! Our goal is to list all the projects building on Holochain on our website.
