This Dev Pulse is a short one, just two Holochain releases and a few new hApps and libraries — plus one bit of big news: Holochain now has a roadmap!
Holochain 0.0.130: Versatile links, cell shutdown fix
Breaking changes: HDK
HDK version compatibility: 0.0.125
Links got a big change in last week’s release (#1266). There are two main differences:
- The base and target address no longer need to exist on the DHT in order for the link to be valid. This means that you can do fun things like use a string constant as a basis for a link, say,
"all_user_handles", get its hash, and use the hash as a base for links that point to individual user handle entries — all without creating the"all_user_handles"entry in the first place. This saves steps, like ‘ensuring’ that the base exists before trying to link to it, which was always subject to eventual consistency glitches that could result in multiple agents trying to create the same entry. Note: while this does not by itself break compatibility with your existing code, it does relax the host’s built-in validation behaviour. If you want to get the old behaviour, your link validation code can simply call `must_get_entry` on the base and target. - Breaking:
create_linknow takes alink_typeparameter. This is simply au8value that your code can use to create link types, similar to entry types. If you don’t care to type your links, you can simply passHdkLinkType::Any.
Finally, there’s one bug fix: errors in a workflow are logged rather than causing Holochain to abort the cell they occur in (#1279). This fixes a case in which an UnresolvedDependencies error thrown when committing entries during cell startup would kill the cell; it probably fixes other cases you’ve encountered too.
And finally, this is the first release that features a fully automated release process! This has been in the works for a while; the DevOps team (Stefan and Jost) has been creating, refining, testing, and fixing the build scripts for a while. They’re delighted to let computers take over the boring work and are excited to apply their creativity and skill to more appealing challenges.
Holochain 0.0.131: Efficient network rejoining
Breaking changes: none
HDK version compatibility: 0.0.125, 0.0.126
Aside from some excellent documentation about how Holochain hashes are constructed (#1299), the networking module has gotten one small change: when a cell starts up and rejoins a network it already belongs to, it remembers prior arc sizes of all of its peers (also called its ‘neighbourhood’), and starts off with those values (#1287). This reduces a bit of network chatter contacting neighbours and finding out how much of the DHT they’re holding.
Delivery zome: send private messages asynchronously
Damien Douté, Holochain core team alumnus and developer of the SnapMail intranet email hApp, has released a library called delivery-zome. This is the first library that I’ve seen to implement the Mailbox and Asynchronous Private Messaging patterns, which let you send public or private messages to other users when they’re offline. (Can you call them patterns if they’ve never been implemented before? I don’t know. I needed some sort of name for them when I first wrote about them.) It also implements delivery receipts and large message chunking, and will in the future implement read receipts, recipient-to-recipient sharing, automated mailbox polling, and DHT-free delivery using third-party drop-off points.
Damien warns us that this is an early release and hasn’t had a security review, so please use with caution. I’m sure that code reviews and pull requests would also be welcome!
Neighbourhoods MVP (Memeable Viable Product)
Neighbourhoods, a prominent Holochain project stewarded by Sacred Capital (itself a member of the Economikit Alliance, another prominent Holochain project), has released its first working demo hApp. They’re calling it MVP, or Memeable Viable Product. This hApp is a very entertaining demonstration, using emoji votes on meme pics to show how their rep_lang engine and social_sensemaker zome can be used to define the reputationional currencies that a particular group of people might find meaningful.
Custom algorithms let you tailor your feed using the MVP community’s two basic reputational currencies: funny and mind-blowing. You can choose your own preference from four default community algorithms or create your own using rep_lang expressions.
We talk a lot about what’s wrong with social media, and feed-shaping algorithms usually come out at the top of the list of bad guys. Neighbourhoods’ reputational infrastructure plans to do something about that by giving communities and individuals the power to tailor their social media experience to their values.
Status module
This zome library, status, is yet another product of the dev.hc community’s weekly Wednesday Workshops. It’s simple but useful, giving your app the power to track and display users’ online status. The algorithm is straightforward: at a regular interval, each agent ‘pings’ the peers they’re interested in tracking the status of. If they get a ‘pong’ back, that means the peer is active. Both the zome and the UI get involved, using only asynchronous signal passing to communicate status.
This ping-pong pattern also shows up in Lightning Rod Labs’ where hApp, which lets users communicate not just their online status but also their presence on a map (whether that’s a traditional geographical map, or a map of current mood, geographical leanings, or pet preferences, etc).
This is also the first Wednesday Workshop that got recorded and posted publicly. If you’re curious about what these sessions are like, have a watch!
Holochain Roadmap is now live!
As Holo announced in their recent update, Holochain now has a public roadmap. I’m thoroughly excited about this, and I sincerely hope it helps you, dear hApp developers, get an idea of where we’re heading — and plan your development trajectory accordingly.
There are a lot of milestones planned, including ephemeral storage (non-permanent DHT data) and pub/sub (subscribe to DHT change events), but I want to call out one in particular that’s simultaneously the least and most interesting: Stable Validation.
What does this milestone mean? In short, there will be two HDKs: an Integrity HDK and a Coordination HDK. You’ll still be able to keep developing your hApp as you always have, using the entire HDK. But if you decide to use the split HDKs, here’s what will happen:
You’ll be able to build a stable, long-lived core for your hApp, based on a stable Integrity HDK that defines the bare minimum of features needed for entry validation. This will help you avoid most of the unpleasant migrations that would normally come with changes to business logic or HDK version bumps. Only this core will affect the DNA hash.
In order to support the stability and longevity of your hApp’s DHT, the dev team is making a commitment to changing the Integrity HDK as rarely as possible. This also means reducing the number of third-party dependencies in the Integrity HDK; that way, there’ll be fewer bug fixes and security patches to force us to bump the HDK.
This also frees up the Coordination HDK to change more frequently and give you access to new features, as changes to zomes marked as coordination zomes won’t affect your DNA hash (you'll even be able to hot-swap them).
I plan to talk more about this when it's included in a release — just wanted to give you a taste of what’s to come!
Cover photo by Annie Spratt on Unsplash
