Summary
Happy New Year to our community! We hope you spent time enjoying the holidays — we did too! This week’s work was on the modest side; you will find the Github activity lighter with fewer commits and pull requests as our devs were getting a well-deserved break. They will be back in full force next week and returning to their regular development cadence.
We’re currently laying the groundwork for two important pieces; capabilities-based security, which we discussed last week, and ‘signals’ (or notifications), which we’ll address later in the pulse. Distributed apps need a lively, responsive experience with strong personal safeguards in order to become the choice of everyday users.
We’re also introducing a Holochain 101 educational section in this pulse to help developers become more familiar with Holochain core concepts.
Highlights
1. Signals: Better Debugging Experiences and Responsive User Interfaces
2. Holochain 101: Links Deep Dive
Details
1. Signals: Better Debugging Experiences and Responsive User Interfaces
*Preparations work for signals — get notified about things happening inside a hApp!
Notifications are the beating heart of most of the applications we use every day. We can debate about what sorts of notifications are healthy for our souls, but we probably agree that our apps should have some way of letting us know when something important has happened. So far, Holochain’s only tool has been ‘polling,’ in which the user interface asks the back-end, “anything new?” — every second or so. This is inefficient and power-hungry.
We’ve recognized the need for something better for a long time. Our aim is to give developers the ability to listen for all sorts of events to which their apps can respond in real time. You will be able to create these events yourself (e.g., someone commented on your cat photo) and have your GUI listen for them.
This will make hApps feel as lively and responsive as traditional server-based apps, without the processing and network overhead of our previous prototype — or the glacial pace of blockchain consensus.
The first set of listenable events (or ‘signals’) will be things only developers get excited about — internal events fired by the core itself. These will be exposed to debugging tools, although some of them may be exposed to zome functions too. Currently, when you’re running multi-agent scenario tests, agent 2 has to keep polling the DHT until it sees the data that agent 1 published. On one hand, this is great because it mimics the behavior of a real-world network. On the other, it can be frustrating to do this checking when all you want is a test result.
Currently, we’re laying the groundwork. In the future, we’ll enable you to hook into the same low-level events that enable detailed logging, so you’ll be able to see when agent 2 actually receives that piece of data. Look for it in a coming release!
2. Holochain 101: Links Deep Dive
What do links enable?
A distributed hash table (DHT) is a non-standard sort of database. Because of the way data is stored, it’s essentially unsearchable. Links are a way to create relationships, and hence meaning, among all the pieces of data. This is how you find things in a DHT.
Recall that hApps use a DHT to store app data. That data is literally spread across many devices, indexed by its unique fingerprint (called a ‘hash’), which acts as an address for storing and retrieving it. The surprising consequence of this is that you can only retrieve a piece of data if you either know its hash or are already storing the data on your own device. This pattern is a very good one for distributed networks, because it’s fast and avoids data syncing conflicts between devices. It also, however, makes it impossible to do the sort of queries that developers are used to with traditional databases, since they are executed on all devices.
Holochain introduces a different (unlike table-based queries) tool to make data discoverable, and it’s simple and powerful. It’s called ‘links.’ It’s another type of data that lives on the DHT alongside normal app entry data.
It turns the DHT from a flat data store into a ‘graph database,’ (a network of connected data). The DHT is now a searchable space again; it connects the things you know to things you don’t know, which then becomes the things you know. When you know the address of one entry, you can query for any entries that are linked to it.
When you’re developing a Holochain app, links are a fundamental data type, because they’re really the only way to turn all the app’s data into meaningful, connected information.
What is a link?
A link creates an association between the addresses of two different entries, from the ‘base,’ the known thing, to the ‘target,’ (the unknown thing) in the DHT.
In addition to the two addresses, a link has a ‘type’ and a ‘tag.’ The links’ types have to be defined in your application alongside entry types. For example, a music app might have two entry types called ‘artist’ and ‘album,’ and two link types that connect between them. One link’s type would be ‘artist_to_album’ so you can query the albums that an artist has published. The other type would then be ‘album_to_artist’ so you can query the creator(s) of the album. The tag is a more flexible field, and something that can be set when the link is stored.
How do links work?
When your app wants to find all the albums that an artist has published, it asks the DHT to give you all ‘artist_to_album’ links on that artist’s entry using the `get_links()` function.
The links are stored along with the artist entry itself, so the nodes that are responsible for holding that data will respond with their list of linked album addresses.
Your node can then ask the DHT for the actual album data at those addresses, which will be held by other nodes. This is how you go about getting data in the aggregate back from the DHT.
