Summary
The past week has seen the demo of a new Holochain hApp, a prototype mutual credit currency. Forum members have already been playing with it, and its creators have presented it at an Open Coop webinar. Come to the Holochain Forum and connect with the creators and participants and play with a new way of sharing value!
The community has also been busy exploring best practices for hApp development together. In particular, the Asia-Pacific Hackalong group has recently been tackling the issue of modularity for shared code. Successful collaboration will need the voices and agreement of many developers, so I encourage you to get involved in this important conversation.
And finally, there’s an update on the promised Holochain release and why we’re reverting back to v0.0.47 and cutting a new release with fewer changes.
Highlights
- Play a mutual credit currency game with other Holochain users
- Dig deep into hApp dev best practices with the community
- Holochain v0.0.48 cancelled, Holochain v0.0.49 released
Play a mutual credit currency game with other Holochain users
Way back in ancient history, before Holochain or even Bitcoin existed, the Metacurrency Project was exploring ways to use technology to power currencies that respected human sovereignty and gave visibility to the diverse forms of deep wealth that exist in the world. Many of these explorations took form in software and were used by various people over the years.
After roughly a decade of thinking, building, and watching projects like Bitcoin struggle with unintended consequences of their designs, the Metacurrency Project decided to concentrate on building and releasing one component of their larger vision of Ceptr, a nervous system for the globally connected world. This component was a peer-to-peer data integrity engine, presented as an antidote to blockchain’s reductivism and scalability issues. Now we call it Holochain.
One of the intended use cases for Holochain is to enable peer-to-peer currencies of all sorts. Money is the first thing people think of when they hear ‘currency’, and at Holo one of our favourite types of monetary currencies is mutual credit. You can think of mutual credit as a peer-to-peer credit system, in which each participant issues currency units backed by their promise to deliver value to the economy in the future. Or you can think of it as a group granting each of its members the ability to access a shared credit pool whose size is tied to the economic value of all the group’s members. Either way, it’s perfect for a peer-to-peer application framework like Holochain.
Mutual credit was the ‘gateway drug’ that got me hooked on Holochain in the first place, because I think it has the potential to empower communities to take ownership of their economic lives. That’s why I’m so excited to see a real, usable proof-of-concept for a Holochain mutual credit currency. Guillem Córdoba, Hedayat Abedijoo, and Tatsuya Sato, three passionate developers from around the world who have been supporting the community in many ways, have collaborated to create the Community Mutual Credit hApp. The UI is easy to understand, and the code has good examples of patterns that are appropriate for cryptographic peer-to-peer tech.
If you’re curious about what a currency app on Holochain feels like, get involved in the game and experiment with us. If you’re using macOS or Linux, it’s fairly simple to get going. (Note that you’ll need to install the Nix package manager first.) If you prefer not to muck around in the command line, it’ll be available via Holoscape soon.
You can also watch the OPEN 2020 webinar where Guillem, Hedayat, and Grace Rachmany (a Holochain Special Contributor and DAO expert) demo Community Mutual Credit, explain how it works, and talk about why mutual credit is important.
Under the hood: a look at the design patterns at work
As developers it’s tempting to just port over our existing ideas about how applications should work, but Holochain is different, so it pays to slow down and challenge those ideas. Holochain enables some patterns that aren’t possible in centralised architectures, and it makes other patterns harder to implement. When you grasp what Holochain is capable of, you can take better advantage of its strengths and avoid creating something that works against the grain.
There are two interesting patterns that show up in the Community Mutual Credit hApp. Both are unique to agent-centric P2P and don’t make much sense outside of it. One is social triangulation and the other a lobby pattern.
Even though they might not be familiar to you as a developer, they will probably feel quite familiar to you as a social human being:
Social triangulation allows the existing members of a DHT to ‘vouch’ for a person who wants to join. Here’s an example of how it works:
- In real life, Alice, Bob, Charlie, and Diane are good friends. Bob, Charlie, and Diane belong to their town’s mutual credit hApp; Alice wants to join too.
- The mutual credit hApp requires two existing members to vouch for a person before it allows them to join the DHT. So Alice gives her public key to Bob and Diane and asks them to vouch for her.
- Bob and Diane commit ‘vouch’ entries, containing Alice’s public key, to the mutual credit hApp’s DHT.
- Bob and Diane tell Alice that she can now try joining the DHT.
- On startup, her copy of the DNA publishes her agent ID, which contains her public key.
- The peers who’ve been chosen to validate Alice’s agent ID check the DHT for any vouches for her public key, find Bob and Diane’s vouches, and mark the entry as valid.
- Alice is now part of the DHT!
You can find an implementation of this pattern in the repo holochain-open-dev/social-triangulation. (Note: the maintainers plan on refactoring the code in the next couple weeks to work around a known issue in Holochain—see below for more info.)
The lobby pattern creates a public space for members of a privileged DHT (such as the town mutual credit hApp above) to interact with non-members. Within the lobby DHT, non-members can ask existing members for permission to join the privileged DHT. This saves everyone the hassle of manually copying and pasting public keys because they can be communicated directly through Holochain.
Guillem created a lobby DNA by combining Tatsuya’s usernames zome (holochain-open-dev/profiles-zome) with his own remote bridge zome (holochain-open-dev/remote-bridge). Here’s how it works:
- Bob, Charlie, and Diane already belong to the mutual credit DHT, as in the above scenario. They also belong to the lobby DHT and have advertised that they will allow ‘remote bridges’ to the mutual credit DHT—that is, agents who don’t already have a connection to it can ask Bob, Charlie, and Diane to make zome calls in the mutual credit DHT on their behalf. (Remember that Holochain is an ‘agent-centric’ framework, which means that apps don’t connect to other apps—each person connects their app instances together.)
- Alice joins the lobby DHT with the username ‘alice_backyard_chickens’. Her app instance checks how many vouches her agent ID has, so she can ask for more if needed.
- That information is hidden in the mutual credit DHT, so her app instance uses the remote bridge zome to ask Charlie’s app instance to make that call for her. Charlie tells Alice she only has one vouch from Bob.
- Now that Alice knows she needs another vouch, she phones up Diane and asks her to vouch for the username ‘alice_backyard_chickens’.
- Diane types the username in. Her app instance looks up the public key attached to that username, vouches for it in the mutual credit DHT, and notifies Alice.
- Alice’s app instance checks her vouch count again, discovers that she has enough, and joins the mutual credit DHT. Her peers validate her agent ID entry and let her in.
There are a lot of other interesting patterns and reusable libraries in this hApp. If you want to explore the code, check out the repo holochain-open-dev/community-mutual-credit.
Dig deep into hApp dev best practices with the community
As the Holochain developer ecosystem matures, it’ll become increasingly important for devs to share bits of reusable, open-source code with each other. Most successful ecosystems have a ‘code bazaar’ which accelerates innovation and reduces duplicated effort. We’re in early stages for hApp development right now, so it makes sense to come to agreement on what it looks like to share code—what a well-designed reusable module looks like, what conventions third-party developers should expect, and what common modules are needed the most right now.
The Asia-Pacific Holochain community has been hosting weekly ‘hackalongs’ for power users, focusing on various advanced topics. Recently, the ongoing focus is on modularity.
Get involved
- Session 1 video: Open discussion on modularity
- Session 2 video: Special Contributor Philip Beadle shows off his Chimera + CRISPR project, a hApp runtime container with an integrated development environment that lets users modify and mix hApps together.
- Telegram discussion on modularity and open-source development on Holochain
- Forum discussion on modularity
Holochain v0.0.48 cancelled, Holochain v0.0.49 released
Last week I promised an upcoming release of Holochain that would improve performance and fix a bug. During this work, we introduced a regression in which the sim2h server and individuals’ nodes didn’t always agree about who was holding what data. So we’re recommending that people not upgrade to v0.0.48. Instead, we’re rolling back to Holochain v0.0.47-alpha1 and cutting a new release, v0.0.49-alpha1, which is basically the same as v0.0.47-alpha. The only difference is a few changes to third-party library dependencies to fix zome compilation failures.
This new version hasn’t been ‘blessed’ yet; we’re expecting to do that next week. In the meantime, you can use the advanced installation instructions to upgrade to Holonix 0.0.75, which includes Holochain v0.0.49-alpha1.
Summary for Holochain v0.0.49-alpha1
- Changed: Changes from v0.0.48 rolled back
- Bugfix: Futures crate dependency updated to resolve upstream bug; fixes inability to compile zomes
Known issues
- Even when an agent is an authority for an entry, the conductor always hits the DHT when getting links on that entry. This causes performance issues in cases where the agent ID entry is used as an anchor for async notifications.
- Long-running zome calls block other calls, causing sluggishness in UIs.
Development status
Latest
- Holochain Core: 0.0.49-alpha1 | Changelog
- Holonix: 0.0.75
- Tryorama: 0.3.4 (blessed)
- Holoscape: 0.0.9-alpha (contains Holochain Core 0.0.47-alpha1) | Download
Blessed (available via https://holochain.love)
- Holonix: 0.0.73
- Holochain Core: 0.0.47-alpha1