We’ve got a follow-up to Holochain 0.2.6, which was a big one (it was the first recommended release in the 0.2 line). This one brings a new ability to manage clone cells from a coordinator zome (yes, you read that right!), and the Rustdoc is now building again (a blessing to any devs who have needed to read the 0.2 documentation). There are some breaking changes, but only for those who are using the conductor APIs directly rather than through a client.
I also want to mention The Weave, a project that my colleague Eric and a few close collaborators have been working on in various forms over the years. Originally demoed as a groupware container called We, the philosophy behind it has matured into a full vision for end-user-composable applications. What the heck does that mean? Skip to the bottom of this article to find out.
Holochain 0.2.8: Fix WebSocket binding
Release date: 30 April 2024
HDI compatibility: 0.3.x
HDK compatibility: 0.2.x (upgrade to 0.2.7 or newer to get the new features)
JS client compatibility: 0.16.x
Rust client compatibility: 0.4.x
This is a patch release that fixes the port binding issue in 0.2.7 (#3731). We now recommend this release for general development.
Holochain 0.2.7: Backend clone management, Websocket fixes, documentation
NOT RECOMMENDED FOR USE
Release date: 9 April 2024
HDI compatibility: 0.3.x
HDK compatibility: 0.2.x (upgrade to 0.2.7 to get the new features)
JS client compatibility: 0.16.x
Rust client compatibility: 0.4.x
NOTE: We’re not recommending this release for development work or distribution to end-users. We introduced a change to how Holochain binds the conductor API websocket to local interfaces, which caused it to get confused when the local interface supports both IPv4 and IPv6. If you scaffolded a hApp with Holochain 0.2.7, we recommend you run cargo update and nix flake update right away to save yourself some hassle.
That said, there are some interesting changes in here that you should know about!
The first big news is that clone management API functions, which were previously only available in the app and admin APIs, are now available as HDK functions. There are a few differences:
create_clone_cellonly takes an existing cell ID, not a role ID.delete_clone_cellwas previously only available to the admin API.
The second point probably needs a bit of explaining. Unlike disable_clone_cell, delete_clone_cell is a somewhat destructive operation, because it makes it impossible to bring a clone cell and its data back to life (although the data is still technically recoverable if you know how to open up the database). That’s why it’s never been part of the app API where any old client could access it. These new HDK functions, by contrast, can only operate on the hApp that the calling cell lives in. We’re working on locking down the app API so only clients authorised to access an app can actually access it, which means we could safely make delete_clone_cell available to clients, but in the meantime this gives you a way to securely clean up cells once they’re no longer needed.
If you think you’d find it useful to manage clones from the back end, we’d like you to try out these new HDK functions and tell us what you think. We may, for instance, change create_clone_cell to match how the corresponding app API function works in 0.3 or 0.4.
The other big news is that we’ve cleaned up the WebSocket code, so the app and admin APIs should have fewer bugs such as dropped connections (particularly when the conductor hits 100% CPU consumption). This does result in breaking changes, but only if you’re writing a Rust-based app that consumes the holochain_websocket crate directly. Anyone who calls the conductor APIs instead (which is most of you, including those who use the officially supported JavaScript and Rust clients) won’t be affected. If you don’t know whether you should care about the breaking changes, then you’re one of the ones who shouldn’t 🌝
Lastly, holochain --build-info now tells you the Lair keystore version.
Read about it all in the changelog, and make sure you scroll down because all the above updates happened in the two RCs before this release.
Holochain 0.1 retiring, 0.3 entering RC phase, 0.4 release cycle started
Now that Holochain 0.2.8 is the recommended release, the 0.1.x series won’t receive any more updates, and we’ll eventually shut down the centralised infrastructure that supports 0.1. We don’t have a specific time for shutting it down, but it should be considered end-of-life. We’re recommending that all developers still using Holochain 0.1 update their hApps to Holochain 0.2.8 now and distribute the update to their users as soon as possible.
Now, on to Holochain 0.3. Most hApp devs are already using a weekly release of Holochain 0.3 in their work, for instance Moss (see below). It contains a lot of stability and performance improvements that will be a welcome upgrade for devs and users.
We’ve decided it’s time to acknowledge this reality and put an API freeze on Holochain 0.3.x. The first release candidate should be out soon. The develop branch of the holochain/holochain repo, and the weekly channel of Holonix, are now tracking the 0.4.x release series. If you’re already on 0.3, you’ll want to change the channel from weekly to 0_3_rc so you don’t get bumped accidentally to 0.4 on your next nix flake update:
// ... inputs = {
versions.url = "github:holochain/holochain?dir=versions/0_3_rc";
// ...Once the first 0.3 release is recommended for general use, 0.2.x will go into maintenance mode, only receiving critical bug fixes as needed.
Note: Some devs may have seen a 0.3.0 release on crates.io or GitHub. This was an automation error, and we’ve removed it from crates.io, so the first official version of Holochain 0.3 will be 0.3.1 or higher.
The Weave: growing thrivable social fabric
I’m a big fan of tools. That’s why I like using my computer: it’s an infinite box of tools that I can use to get work done, communicate with friends and colleagues, create art, organise family memories, etc. And I like tools that feel like tools — small programs that do one thing, do it well, work well with each other, and use common data formats. This is brilliant, if you ask me, and it makes me feel like I have superpowers whenever I need to do something complicated.
I am not a big fan of silos. It frustrates me that my colleagues and I have to log into six or seven different cloud platforms just to get a Dev Pulse published. And each of them has its own separate content organisation system, discussion system, etc, etc. We end up having to recreate the same structures in multiple places. (And so do the developers — if you’re creating a kanban app, you can’t just drop Slack into it and get commenting for free; you have to write your own commenting feature from scratch.)
As far as I can tell, this silo thing isn’t designed to serve my colleagues and me. Perhaps it isn’t even designed. It’s probably just an accidental outcome of companies working with what they know. Or maybe it’s some business folks deciding they can only make money if they hold their customers tight. But whatever the reason, it’s wasteful and annoying.
That’s why, when my colleague Eric showed me what he and the Lightningrod Labs team were doing with We (now called Moss) in February, it was like he’d opened the door in a stuffy room. This was exactly how I’d wished my applications worked for at least fifteen years. Sure, it was a little rough around the edges — Eric acknowledged that — but I could see the potential lying just beyond the bugs and unimplemented features.
The vision of The Weave: a protocol for social spaces
I won’t get too deep into the philosophy — I’ll let The Weave’s new website do that — but I’ll give you a little teaser: what HTTP did for information, Holochain is trying to do for social spaces. But HTTP alone wasn’t enough. It needed HTML, CSS, and JavaScript to make an experience that people would want to use. In a similar way, the Weave is a formal specification that overlays a set of design principles to make Holochain more accessible for devs building social tools.
HTML introduced pages and, most importantly, hyperlinks as a way to connect them together. This made the Web make sense. It was just enough structure for developers to run with, and it resulted in an explosion of creativity that gave us the web of today. But neither HTTP nor HTML gave us open standard for social spaces, so these concepts got enclosed by big players like Facebook and Twitter.
Holochain gives us open standards for permissionless social spaces. And what HTML et al did for HTTP, the Weave does for Holochain: assets that belong to your group can be linked together with ease.
How does this work?
- A tool is something that a group can install, and it gives them the power to work with assets of a certain type (chat threads, images, files, folders, kanban cards, calendar entries, etc).
- Wherever it makes sense, an asset can have links on it that connect to other assets provided by the same tool — or some other completely different tool.
And that second point is what changes everything. Now I can add a conversation thread to a calendar entry if I like. I can drop links on my kanban card that point to cells in a table (there’s already an Airtable clone available). We can drop cards, boards, emails, messages, conversations, and drawings into a folder hierarchy that’s shared across all our tools. Or three or four independent folder hierarchies, if we like.
Why do I care about this?
I get excited about this as both a user and a developer. As a user, I’m not constrained by the walls that others have created for me — I can stitch together tools in ways that make sense for me. As a practical example, my team can gather all the stuff pertaining to one Dev Pulse into one place. (Or will be able to, once someone comes up with a replacement for Canva.) I expect this will smooth out a lot of the bumps we face when we’re working on a written piece.
As a developer, it means I won’t have to reinvent everything when I eventually make my seed swapping hApp into an awesome working product. I won’t have to re-create messaging, reputation, user profile, or categorisation features — I can just focus on the core thing that matters, a way to let people find each other’s seed packet offerings.
Eric believes this sort of easy composability means that developers will feel empowered to create that little tool they’ve always wished existed. When you only have to focus on your core thing, the task seems much less frightening.
I think that part of the reason more great tools don’t get built is that people think you have to have a full-featured app, a team of devs to handle feature requests, and a business model in place for when your user base (and your cloud hosting costs) scale 100×.
But what would you create if you only had to think about one little thing, the thing you care about most? What is that thing for you?
I’d love it if you shared your little tool ideas in the The Weave channel on our Discord.
In the meantime, download Moss, the first ‘frame’ implementing The Weave, try some of the early stage tools, and read the spec to get an understanding of how tools in The Weave are made for composability.
(Fun fact: the equivalent of a ‘browser’ in The Weave is called a ‘frame’, a word that my lovely bride — a weaver — contributed! A frame loom is a special kind of weaving loom used for making tapestries. Kinda fitting for a program for groups weaving a shared story, don’t you think?)
Cover photo by ALAN DE LA CRUZ on Unsplash
