The following is a rough transcript which has not been revised by The Jim Rutt Show or by Art Brock and/or Ferananda Ibarra. Please check with us before using any quotations from this transcript. Thank you.
Jim: Today’s guests are Ferananda Ibarra and Art Brock of Commons Engine and the Holochain projects and various other things. Got to ask you a quick question here before we go on, I’m actually reading a book called Free, Fair, and Alive: The Insurgent Power of the Commons. Have you ever read that book?
Ferananda: Yes. I’ve not only read that book, but David Bollier contacted me to help them to work on the Holochain section and Commons Engine was mentioned there. Then I spent a whole week with them in Germany, working on ontology and patterns for the commons. Yes, read it.
Jim: Oh, that’s great. As usual listeners, we will have links to everything we reference whether companies, websites, books, papers on the episode page for this episode, so don’t feel like you have to take notes. Just go to the website jimruttshow.com. You’ll have links to everything we talk about. That book I’m about 20% in, I’m quite taken away. I’m reading it slowly and carefully. I guess there was probably a relationship with that.
Jim: Art has worked to unlock the secrets of the social DNA by which people operate and the critical role of currencies for programming these patterns. He’s also designed lots of currency systems, the list is almost endless, scientific research, fishery management, stock options, community based economic development, et cetera.
Jim: Ferananda has started off in the area of collective intelligence, which is certainly a strong interest to our audience. She then began working in communities of intent, intentional communities we might call them in our space. There, she realized that money or we would probably abstract a little bit and talk it about the social system signaling that is like money was critical. She and Art and the other Holochain guys found each other and I think that’s how we are today.
Jim: Let’s jump in a little bit first and talk about Holochain itself. We’ll then later talk about holo, HoloPort, HoloFuel, the HoloToken et cetera. Let’s talk about the Holochain itself. As I was doing my research, one of the analogies that you all used I found very illuminating, which was describing the Holochain approach as agent-centric, rather than data-centric as compared to say Bitcoin and Ethereum.
Jim: In particular, you compared Holochain in ways to get, could you start with talking about agent-centric computing and how that’s fundamentally different than what Bitcoin and Ethereum are doing?
Art: Sure. The thing that there is in common is that we use hash chains, which is a cryptographic structure that can give you essentially some characteristics of immutability, where you can’t really go back and change the past once hashes of things have been shared. It kind of locks in the past. There’s kind of the common ground. One of the better ways to think of Holochain less like blockchain than like get plus BitTorrent.
Art: Instead of managing consensus of what blocks have been committed officially to one ledger, every agent has their own source chain, we call it. Because all data is sourced in a source chain and it is only the data they authored. Their local state changes that are written to that chain. Then, published to a DHT as the shared ledger global visibility space. That’s an eventually consistent system. It’s not a consensus driven system.
Art: That makes for very different characteristics of performance. I would assert, it actually models the way the real world works. The way we see things work in physics and biology. Hence, some of the naming of things in Holochain, like application code is called DNA, things like that. It’s a pattern that is inspired by nature that gives us the scalable coordination.
Jim: Yeah. One of the things that struck me immediately and those who have listened to the show before know that I will rant about Bitcoin and how the main thing it’s doing is accelerating the heat death of the universe, right? It strikes me that as you say, most real world problems don’t actually need to be written to a global ledger, right? That everybody in the world has to duplicate, et cetera.
Jim: Like Ethereum’s case, it’s even more absurd than that. It’s essentially saying every computer program in the world doing class X of application, in the case of Ethereum, smart contracts, has to run on the same slow computer. Who in the world would design a system like that, right? Yet, those are two of our more popular distributed ledger applications out there.
Jim: As I dug into Holochain, I said, “This looks like it might actually scale and be a reasonable fit for the real world.”
Art: Yeah, if I could say a little bit more about the agent-centric aspect, I think distributed computing gets a little hung up by traditional computing, in terms of we’re used to thinking that we can hold the whole data set, the whole data space and that that space has sort of its own inherent truth to it. This is the kind of data-centric mentality. What we’re suggesting is all of that data actually came from somewhere.
Art: Whenever it was created, it was an assertion by an agent. If you break that from its provenance, if you break data from where it came from, you actually have already lost data integrity. If you were to ask me what the temperature in the room that I’m sitting in right now is, there’s a thermostat over on the wall that would give you one thing. If I had one of those little infrared devices that could measure different temperatures, I’d click it over the lamp over there, that kind of thing and we get lots of different temperatures.
Art: Then, if we wrote those to a database, where Arthur used this device, and I signed them to a database. Then, we find out tomorrow that that infrared little gun trigger that I was using to measure the temperatures is 20% out of calibration. Now, we know which data was affected, which data is not true. When you just start off assuming that data has sort of inherent truth and you break it from where it came from, you’re starting with problems.
Art: Holochain is really coming from this agent-centric perspective that you write data to your chain, it’s signed and shared. You always know where the data came from. It can always be verified and validated against that local state. That just lets us create very different kinds of patterns of sense making and social coherence that I would say go far beyond the current scope of smart contracts and such.
Jim: Okay. For our audience, we’ll break this down into more bite sized pieces. When I start to develop something or start to be a user of Holochain, I have a private key and I use my private key to sign additions to a local blockchain called the source chain, is that correct?
Art: Not a blockchain just a hash chain. Yes.
Jim: I read it looked like the math was pretty damn similar, right? Okay, that’s call it a hash chain. We use the same trick that you sign the block including the previous signature, so it can’t be hacked, et cetera.
Art: Yup.
Jim: What do you call each thing that you write? What’s the name of the block that is written to the chain?
Art: It’s just an entry like an entry in the database or whatever. We just call them entries. Rather than being a block of many entries.
Jim: Great. Of course, one of the nice things about that is that you don’t require an expensive proof of work to have the right to write to your source chain, presumably the only credential you need to write to your source chain is your private key.
Art: Exactly.
Jim: Okay. Of course, this gets me into one of the great bugaboos of our whole world which is private keys and the management thereof. Have you guys done anything to help with that problem?
Art: We have. Holochain has an API we call DPKI for Distributed Public Key Infrastructure that actually uses a Holochain app in the background as a key management infrastructure so that you can revoke or replace keys. Because right now, in the blockchain world, if you lose your key or if your key gets compromised, somebody else gets hold of your key, you’ve lost your tokens or you’ve lost control of your smart contract or whatever the thing is.
Art: In the case of Holochain, if your laptop gets stolen and you had some Holochain apps on that, you could use another device to revoke those keys or replace those keys with new ones and resume control of your identity essentially, of your agency, because of having key management in place.
Jim: That’s very good and very important because that’s, again, people have heard me rant about this before, one of my critiques on traditional blockchain applications utterly depended on your private key. We already know that some non-trivial percentage of Bitcoins are probably lost forever because it died or lost, lost their private key.
Jim: In fact, I actually have some very early Bitcoin that I have lost. Back in the days we used to be able to get a tiny fraction of a Bitcoin for sending a text message to somebody, it was hilarious. I probably have a thousandth of a Bitcoin somewhere on one of my dead computers that nobody will ever see again. We get what we call intrinsic data integrity by signing each element, each entry, going, and then you write it into your local chain.
Jim: You guys make a big deal out of the fact that private data by itself isn’t all that interesting. Why don’t you guys riff on that a little bit?
Art: Sure, actually, if I can even just touch on the intrinsic data integrity aspect of what you were just talking about. Blockchain has been kind of blown up to be about tokens and about currency. I think what’s interesting is, it’s about anybody being able to hold and serve the data, because the data has intrinsic integrity, you can tell that it hasn’t been tampered with, right?
Art: In the case of what you’re talking about, we can actually have shared sense making spaces and trust each person or anybody on the network to be an authority for the data. What I mean by that is like, who wouldn’t love to be able to log in and change their bank balance? Say, I’ve got 5000 more dollars today than I did yesterday.
Art: The thing that prevents that in this story is that you can’t tamper with the data, the data is tamper proof. There has to have actually been a transaction that somebody else signed for that money to exist. All state changes are signed by the people whose state is changing. In the case of implementing a currency on Holochain, which doesn’t have one built in by the way, like most blockchains do.
Art: We recommend you do it basically like double entry accounting. The two agents whose state is changing, both sign the same transaction to each of their chains, and they give each other the counter signatures. Then, you have local state changing and you don’t need global state or global time to be able to make this work.
Jim: We’ll go into that application, a particular small scale currency application a little bit later. When we have our data written to our local source chain, it’s not all that useful sitting on our own computer, probably some things would be all right. Maybe I want to do a catalog of all my DVDs or something. If I want to share it with people and build online environments that do actual work, you need to replicate, get that data out so other people can have access to it.
Jim: Of course, this is the tricky part of distributed computing in Facebook or something, all the data is written in one place or at least it looks like it’s in one place. It’s easy to search. It’s one big, from the user perspective, bag of searchable data much more tricky in distributed land. You guys have the idea of peer replication and validation. Maybe you could describe that a little bit and how do two peers decide to peer with each other.
Art: In Holochain, each Holochain application is a separate network, if you will. It’s a separate peer-to-peer encrypted network. You have to be running the same application to be a peer of others. For example, if you take a chat app like a Slack application and you want to create a private Slack team, you could fork an existing instance by just changing a little number in there. Changing the UID in there to make your own little network that has its own identity and send people an invitation code to join your network.
Art: They become peers in your network by installing that software, installing that instance of the Slack app. Then, the one trick there is a bootstrapping process for peers to start finding each other. You would need to give an address. Right now, we’re stuck using the centralized domain name resolution type process for addresses just because it’s universal.
Art: That’s the one little legacy part of centralization that’s in Holochain is that we have to bootstrap somewhere. Then, the peers just gossip with each other to manage the sharing of that information of the Slack chats, for example, or of the Twitter and that kind of thing. So much of the internet now is web 2.0. It’s data that is contributed by the users. Yet, that’s all given to some central corporation, when there could be ways that we could just hold these things ourselves without needing to basically have a surveillance corporation in the middle that’s making money off of selling your data to advertisers.
Jim: We know there’s a lot of interest particularly in our Game B world of getting away from these centralized data controllers and exploiters of users, right? As we say, if you’re not paying for their service and you are the product. You’re basing your tangents being hijacked in various pernicious ways. If we had control of our own data, we’d get away from that.
Jim: To make it clear, what peering really means is that multiple people, two or more people are using the exact same app, which means that the app itself is signed and owned by a private key or an address. Is that approximately correct?
Art: Yeah, the app code is actually signed into the first entry of each person’s source chain. If that source chain doesn’t start with the same hash, then you’re not running the same code. You don’t have the same rules because of the peer validation you talked about, we actually have to be able to check each other’s work. That has to be reliable, which means we have to have the same rules for checking each other’s work.
Art: That’s actually the very first entry of everybody’s chain so you can check that hash and make sure we’re all on the same rules. It’s also part of the network encryption salt, so that you’re not even talking with somebody that doesn’t have that hash and isn’t in that encrypted network.
Jim: Okay. One objection I have read about that is that means that every time you do even the most rudimentary bug fix on an app, you essentially have to have everybody fully reinstall the app. In fact, in some real sense, it’s a different app. How do you respond to that objection to this architecture?
Art: I would say that is a real phenomenon of distributed software. That objection comes from a centralized software viewpoint where everybody has to go to one authority and that one authority is managing everything. Therefore, you can just change it in one place, nice and simple, right. If it’s distributed software, then the people running it have to receive a new distribution of the new version and be able to move to that new version.
Art: Part of what we encourage in Holochain to reduce the pain of this is, first of all, not making huge monolithic applications but instead building small microservices that work together and have pretty reliable narrow functionality. In the DNA, you keep only the data integrity management, the data validation and integrity management rules. All of your UI stuff should be outside of the DNA. You can change that stuff and people can be using different versions of UIs and that’s fine. They’ll still have the same peer validation for checking each other’s work.
Jim: That brings up a very interesting question. Let’s say, it is a distributed Slack channel. If the app changes, i.e. the signature on the app changes for let’s say, even a fairly rudimentary bug fix, does the data have to be re-replicated as well? Or, are the data and the app some set separate on my machine? I suppose I have two years’ worth of slack data for a 50-person project could be a lot of data.
Jim: When the new version of the app comes out, this whole lot of data have to be replicated too.
Art: That’s great question. It really depends on which type of app it is you’re talking about. What you can do with Holochain, the apps being microservices or small and lightweight. You can be running multiple versions of an app, if need be. One of the things that we do to address the … simplifying the pain of having to have everybody migrate from one version to another is that we have this concept of closing entries and opening entries on your chain.
Art: Where you can say, okay, I’m closing down working on this version and have migrated to this new DNA. In that new DNA, after your first entry is where you put in the DNA code and your agent key. Then, you can have an opening entry that says, I just came from this other DNA hash. That way, you can actually have queries that span across DNA versions and across DHTs, where you can be running them both or running multiples and be querying into your history across multiple versions, and so that we can try to provide more experience as possible there.
Jim: I can see that’s going to be a little tricky from a application development perspective. In fact, I interviewed Steven Levy a couple days ago who recently wrote a great book about Facebook. One of the things we talked about, one of Facebook’s competitive advantages was it was one of the first major online companies to be essentially built with DevOps in from the very beginning so that they were pushing four or five new updates to the Facebook software every day.
Jim: We know of course now, Google, nobody sees the same Google. Everybody gets a different Google because they’re testing hundreds of different parameters on the user interface every day. It strikes me that that hyper agile DevOps-driven, user experience driven way to evolve software incrementally would be impossible to do in this environment.
Art: Except as you said, most of those changes are to the experience to the user interface, not to the underlying data integrity. It’s only when you’re changing the underlying data models, data structures, or the permissions and such that it would affect the validation that you would actually be changing the DNA. You could have many, many different versions of UIs running.
Art: In fact, part of the beauty of it is you could allow, again, it’s sort of an agent-centric perspective on this where I could customize my own UI or run my own skins or pull different data from different applications into a single UI that don’t provide that kind of unified interface. Because what matters from the DNA perspective is that no state change is happening that is invalid. You can collect that data and display it however you would like.
Jim: Yeah. Though in the case of Google, in particular, Facebook as well, there’s sort of a deep marriage between the data and machine learning algorithms which decide how it’s presented. From the UI layer, those two things kind of live together. It’s the machine learning layer that’s evolving probably even faster than the formal UI.
Art: Exactly. You would put that machine learning layer for the UI outside of the DNA. It doesn’t change the structure of the data necessarily. It just will filter which data like rank which pages come in your search or which posts in your feed and that kind of thing. This is, again, the beauty of I could use one algorithm and you could use another to display your feed. We could each get what we want that way. Where right now on Facebook, we get what Facebook and its advertisers want.
Jim: Exactly. I call it the Zuck algorithm, and I hate it. If you can actually pull that off in a way that really works for real developers of application, then this may well be the right platform to replace Facebook with at some point. Let’s go down a little bit into the weeds a tad, as I understand it from my relatively modest readings.
Jim: The actual applications are created out of components called Zomes, which are lower level components, which are then packaged in a way that is not that different from microservices called DNAs. Could you talk just a little bit about the distinction between those two and why you chose to do it that way?
Art: Yeah, Zomes was just our silly word for modules based on chromosomes in DNA. Like, what are some of the subsections? How might you modularize your code because, generally speaking, people want to create good modularity for sharing and maintaining code and reusing portions of things.
Art: The idea is, a Zome may be a module or reusable portion that you might use in different places. For example, there’s an anchors pattern that you use a lot in Holochain where you use a predictable bit of content to hash. Let’s say, it’s a username, and then you can use that hash to attach a lot of links to find other things.
Art: If it was a Twitter app, it could be your Twitter user handle, your Twitter handle. Then, from that handle, I can find links to your posts, to your tweets, or to your followers or to who you’re following or your favorites or things like that. That handle holds a lot of things together. There’s an anchors API or an anchors mix-in that a lot of applications use.
Art: That’s a Zome that they can just plug in and use this pattern for generating anchors that also create kind of a little directory system in a way of kind of having data be more discoverable. Because on a DHT, data is tricky to find sometimes if you don’t know the hash. How do you go look for it when it’s spread across potentially thousands or hundreds of thousands of computers?
Jim: Yup. We’ll talk about that. I could have a whole section on that. Going to the next level, if we can think of zomes as modules and DNA as the equivalent of small program, is that a fair enough way to describe them?
Art: Yeah.
Jim: Okay. Then, the next level up, I believe you call happs as a bundle of a client, which talks to one or more DNAs using a lightweight RPC? Is that approximately correct?
Art: Yeah, a happ is a way of bundling DNAs and UIs into something that basically can be delivered to an end user. There may be a single UI, there may be multiple UIs, there may be multiple DNAs but it provides an integrated, a singular, experience by bundling it all together.
Jim: As we know, in a lot of real world problems, building that UI is not easy. Do you guys have decent tools for building UIs at this point?
Art: We’ve had a few different iterations of tools. I’m actually very excited about one of the newest ones that’s coming out of one of our guys, Philip, in Australia, who’s been building a bunch of components in Vue using the Vue JavaScript framework. He has been building a Holochain app designer that is a Holochain app.
Art: Holochain essentially replaces GitHub in this way where you can actually use it to manage and share designing information while you’re building an app with other people building the app. Then, there’s this mode, he’s calling a chimera mode, which is like a mashed up animal, if you will, part lion part snake part whatever, right? It’s kind of a mash up mode where you can pull different DNAs together.
Art: He’s defined slots where you can have the UI components, the web components, and from one UI sort of populate into another one and you start having this kind of pluggable componentry for UI components for Holochain apps. Hopefully, we’ll be publishing this in the next couple of weeks because I think it’ll be a fun thing for people to play with.
Jim: Those things matter. I can tell you, in my business career, I did various things. I was an entrepreneur. I was a sole entrepreneur. I was a startup venture dude, all that stuff. I was also a corporate CTO for a number of years. One of the things I saw in the ’90s is sort of the microsoftification of corporate American software. It was driven by one thing, visual basic, oh my god, right? Because it was easy, right?
Jim: They worked off that and build a whole visual studio, et cetera, et cetera. I would not at all underestimate the criticality to your ecosystem of having tools that are easy, indeed even pleasant to use to be able to build the whole stack out. I hope you guys are paying enough attention to that because in my experience, a lot of people in this space aren’t.
Art: Yeah. To me, what Philip has built is a bit of a breakthrough for us. We actually did have a scaffolding, kind of a quick start thing that would almost like a wizard help you build your app kind of thing where you would identify your zomes and some entries and create entry schemas for you using JSON Schema and all that good stuff in the old version. It would generate tests and a basic testing UI, ugly, but basic testing UI and also your basic CRUD functions for the data.
Art: You still needed to go in and do more with the peer validation rules and everything. In terms of like bootstrapping somebody up quickly, it was a really helpful tool. This one was supposed to be kind of the successor to that. Philip went a little crazy and just started getting into mixing and matching all the visual components as well. I’m really hoping that it does create some buzz and stir because it’s the kind of thing where power users can start assembling apps and combining pieces of apps into new things and that kind of thing.
Art: You don’t have to be a power developer, you can really be a power user that can paste things together. I would assert that much of the web emerged that way from people pasting together stuff that they found on other websites and liking that pattern and assembling it together. That’s kind of how we got to where we got to on the web all together.
Jim: Yeah, I used to make that point that even though from my perspective, as a former database designer network protocol aware dude, I can’t imagine anything sleazier than HTTP and HTML, right? Holy shit, who’d want to build a world on that? The reason it happened was you could tell your secretary to go view source and steal the source from an early 1993 web page and duplicate it in 15 minutes.
Jim: That’s why HTML, HTTP took over the world despite the fact that it’s an abomination. It was easy. It was viral. I guess, though, I suppose we’re not supposed to say viral anymore in this time of pandemic. Yeah, those ecosystem things make all the difference in the world. It led us to this horrible thing called the web, which is now not so horrible anymore. Frankly, despite its foundations, not because of them.
Art: What I’m hoping that it accomplishes is actually understanding that Holochain apps can be very small in scope. They can just be your family’s check-in system or something with a small group of people, where blockchain apps tend to be viewed with much greater weight and significance because you’re like writing something in stone forever on a monolithic blockchain.
Art: If you make a mistake in your smart contract, it can be horrifying and have real financial consequences in terms of gas costs or credits lost or different things like that. Part of what I’m hoping can come out of a tool set like this is losing a little bit of that stigma and fear and significance to just say, oh, I can just invite people to play in little spaces. The risk factor in that is extremely low. It’s just sandboxes we can play in.
Jim: Yeah. I can revoke the program if I want to, right?
Art: Yup.
Jim: All right, that’s with your key management system, I can just kill that sucker, right?
Art: Yup.
Jim: Let’s move on to the next part. Frankly, as a database nerd, the thing I found most interesting, I’m not sure everybody will. I thought it was really cool. That really, really serious innovation is your distributed hash table. Particularly, some of the interesting ways that you made that tolerably efficient such as basically making everything a hash, including usernames and sorting basically assigning content to the agent’s name who’s closest to the hash on the content, et cetera. Could you lay out for the audience, what is a distributed hash table and why is it interesting and innovative?
Art: Just starting with the real basics, a hash is like a fingerprint for data. If the data changes, the fingerprint should change significantly. A hash table is a way of organizing that in a key value store where the hash is a kind of key that you can look up the values you’re looking for, you can retrieve the values you’re looking for in a table.
Art: The distributed hash table divides that across many, many different machines, so that nobody needs to hold the whole thing. It’s a way of breaking a kind of database into many little parts. Then, when we do that, we can also have agents or users have addresses in the same address space that the data is stored in. Now, we can arrange the data, we can send it to hosts whose addresses mirror the address of the data.
Art: Whenever you’re looking for data, you just sort of get routed toward the hosts with the closest addresses or the peers with the closest addresses and get back the data that you’re looking for. We can set up some redundancy levels and we can set up gossip and things for being able to have peers that are near each other know about the data that each other are holding. We have kind of a self healing database as peers drop off the network, the other peers near them gossip it more broadly.
Art: As new peers join, they learn about the data in their neighborhood and get that gossip to them. It lets us have an organic living, self-healing database, which is, I think, what we have to have in these sort of peer-to-peer driven systems.
Jim: If I’m building an app, can I set parameters on about how much sharing I want? When we do distributed databases, I occasionally fool around with Apache Ignite, for instance, and it’s a very cool distributed database system that does automatic replication but you couldn’t define the replication rules.
Jim: Can I say, I want at least five copies of every entry or is it less well parameterized than that?
Art: The plan has been that you set a target redundancy level. I say has been because I think it may be changing a little bit as we learn from actually trying to run these distributed systems, individuals don’t tend to know much about the consequences of that decision that they’re making. When they say, I think there should be 100 copies of the data on the DHT.
Art: First of all, because of the self-healing nature of it, what we’re trying to do is manage how many copies are online at any time. Meaning, when peers are gossiping with each other, they’re keeping a little log of my attempts to reach you, what percentage of them were successful, or what percentage of them failed, so that I have an uptime estimate for you.
Art: Then, I know that if the target data, target number, here is 100, but my peers really only have 25% uptime, right, then basically, I need to have 400 copies of the data alive. Since people don’t know that they’re making that kind of decision, often when they say 100 copies now they have 400 nodes trying to gossip data around, which slows the whole system down.
Art: What we’re kind of finding is that we may want to have the default be a kind of autopilot mode, where let the network balance itself and make sure that there’s adequate redundancy and adequate load handling, rather than have sort of a preconceived notion of a single number of redundancy factor be able to provide that. For now, we still have that single number as the target. I think we’re going to be tuning this more kind of like auto tune mode, where we can have applications default to auto tune and only override that in exception cases.
Jim: That’s probably very wise. Again, to help people who want to just try things, right? Because you are absolutely correct trying to actually understand a distributed database and how you should configure it is a problem of nightmarish proportions even for people who know about this stuff, right?
Art: Exactly.
Jim: As you say, even relatively small changes in parameters when you run across the combinatorics of a distributed database can have really big implications. I’m going to take a little sidebar here, I’m going to get to you later but you’ve mentioned the gossip protocol that you guys use a couple times. Gossip protocols are a class of protocols. There’s lots of gossip protocols. It might be useful for our audience, who probably have never heard the term before it to explain what a gossip protocol is. Maybe at least a little bit, what are some of the specifics of your protocol?
Art: Cool. The basic gist, gossip is referring to the same kind of activity that we as humans do. It’s kind of like, hey, what’s new? What’s the news that you’ve heard? In a gossip protocol on Holochain, you connect to other peers and you may have things to deliver to them that you’re intending to deliver to them like saying, “Hey, you need to know about this.” Then, you’re also asking them, “Hey, what have you heard about that I should know?” In Holochain’s DHT representation, we’re able to have a very simple representation of what data a node is holding. There’s their address and then there’s another integer, which is basically the range beyond their address that they’re holding.
Art: It allows nodes with higher capacity to hold more and nodes that are maybe smaller capacity running on a Raspberry Pi with very little storage attached or something to hold less. We have a simple way of knowing what range you’re accountable for of addresses in the DHT. We can say, for my range, given these two numbers, you know about me, you know about my address because it’s literally the address I’m contacting you from. My messages signed by it, it comes from that address and all you need is this one other number to know whether or not any of the stuff that you’re holding or new things you’ve heard about are in my range that you should tell me about.
Art: I hope that kind of … it’s the crux of the gossip protocol. Then, nodes are just doing this on a periodic basis, depending on how frequent they’re seeing new data that like less active applications can calm them the gossip a little bit because the changes aren’t happening very frequently. Very active applications are going to have faster gap gossip, because there’s a lot of changes happening.
Jim: Can you specify that at the application level, essentially?
Art: At the moment, what we’re doing is, again, we’re trying to get more into this auto tuning and more like exponential back offs, where if I haven’t gotten anything new from you, then I wait a little bit longer and I wait a little bit longer. Then, if I start getting new things from you, then that kind of pulls me back into a very active mode, and then we kind of back off and calm a little bit. That’s more built-in to the system auto behavior at this point.
Jim: Okay. Let’s move on to the next topic. One of my favorites, which is hashes, by definition, are cryptic links. They provide no information at all about the data, right, because if they did, they wouldn’t be a hash. However, in an information system, we often want to be able to query on the content. At first, I said, “Oh, damn, another one of these stupid databases of cryptic links, that’s pretty damn useless.” Then, I dug a little further into your materials and I realized that you’ve extended the concepts towards a graph database with what you guys call tags and anchors that make it at least feasible in principle to allow some traversal of the graph that had some content specificity to it.
Jim: Of course, this is a famously difficult problem, right? I’ll just stop there. Actually, I’ll let you talk a little bit about how you make this graph of cryptic links into something that’s at least somewhat searchable.
Art: Yeah. As I mentioned earlier, it can be very hard. You can’t expect to crawl a DHT because by the time you even got around to people that you knew existed, other people might exist and other data would exist and there’s not really a good way. It is inherently kind of an eventually consistent space. What you want to do is build good ways of finding the data through references.
Art: Those references can be in the form of links or those references can be in the form of indexes or those references also can be in the form of chains. Meaning, we already have one topology that every piece of data that got added to the DHT was in somebody’s source chain. I could find from one of your neighbors, I could request kind of your header history, if you were offline, and basically be able to re-crawl your activity, your set of state changes. That’s one way that we can find data on it, right?
Art: If I have your key or address, I could talk to neighbors of yours and say, “Hey, give me give this header history.” That’s really useful for things that matter in a chronological context. Things like monetary transactions, whether your current balance is based on the chain of your past actions, which funds you’ve received and which funds you’ve spent. That topology already exists but what we’ve done like you’ve said with links, is be able to attach links on to essentially anything else and query them as many information.
Art: Then, we have this pattern of anchors, which is a way of giving links a good base to attach to that’s predictable and known like a username or something like that. Then, we even have created the anchors in a sort of tree hierarchy so that you can think of that like a browsable directory file structure, if you will. Where there’s a root anchor that tells you what anchor types exist and those anchor types tell you which anchors exists. If there’s a user anchor type, you could get the list of usernames off of the user root anchor. It creates ways of having the space be discoverable and crawlable and still be distributed.
Jim: Yup.
Art: Indexing is a whole other problem.
Jim: Yeah. That’s a good first step. However, as we know, there’s a big tension between browsing and searching. The way I would describe it is that the problem with browsing is that it puts a burden on somebody to manage a taxonomy. If we remember to the early days of the internet, the Yahoo was actually a taxonomy. You browsed Yahoo, you didn’t search it in the old days. You went down these damn menus layer after layer. Then, other people, Lycos was the first one that was an actual search engine, or I’m not quite sure. Anyway, you can actually do full text searching.
Jim: This is the indexing issue. To bring it back to a tangible example, our old friend, Facebook, love it and hate it. You go up to the Facebook search box, and you type in almost anything and it’s surprisingly often it’ll give you what you’re looking for. How do you do indexing? How do you do something like search on a distributed hash table?
Art: I think that’s going to end up being a number of different indexing strategies. One of the ones that we were using in the go version of Holochain and the apps that we built there, I think is carrying over in this last version, which is basically that there’s an indexing app, another Holochain app. That it’s only being run by nodes that are more substantial nodes, that are online reliably, that have storage space and processing power. You can think of those as servers.
Art: Because we want generally speaking, Holochain apps to be lightweight enough for you to just run them on your phone. From the graphing perspective, we can keep that in scope, and not put too heavy load on somebody’s phone or something like that. If you start running indexing, and this is a peer-to-peer app that everybody’s running, now you’re getting back into the sort of blockchain problem of everybody holding everything and holding an index to everything, or at least holding an index to everything.
Art: Because Holochain DNAs can, our Holochain apps, can bridge to each other locally, what we can do is, you can build your Twitter app kind of thing. Now, you want those tweets to be indexed. You want to be able to search on emerging terms and that kind of stuff. Then, you can have some nodes be index nodes. We can get into the incentives for running an index node in a minute. The way that that works is the index node runs the Twitter app. In our case, it was called, Clutter. They also run the Clutter index app and they register themselves in the Clutter app as an index node.
Art: Then, everybody when they posts, posts to one index node and the index nodes gossip with each other because it’s a Holochain app that’s gossiping, right? You can do queries by sending a direct message to an index node and get back a set of results and then, just query your Twitter app, your Clutter app, peers for the actual things the results you need to load. You get the results list back from one of the indexes.
Art: We built that index pattern using anchors, just using keywords as anchors that then had links that went off to the posts that included those words. Everything that we used in that pattern, we’ve already kind of described on this call. That’s going to have a certain level of performance, that whole kind of index everything as a base word, as an anchor may have performance limitations. There’s not any reason that you couldn’t have these nodes actually just plug in something that’s doing meta searches on the data. Like plug in actual elastic search or something like that and have something outside of Holochain be running the indexing on the Holochain entries.
Jim: Essentially, have the idea of an external service maybe something like that?
Art: Yeah, because this is agent centric, you as an agent can connect things in to your data locally. If you are an index node, then you have all the data that needs to be indexed, and you can be indexing that locally. Then, you can respond to queries using that algorithm, that kind of thing. You can do things outside of Holochain locally. That’s like you were talking about the machine learning for prioritizing results, that kind of stuff. This is a similar sort of thing.
Jim: Of course, you wouldn’t want every user to be re-indexing all of Facebook or even my view into Facebook. That’s the big advantage that centralized systems have, they only index it once.
Art: For resilience, if you want a decentralized system, you probably want decentralized indexes where you might have 20 or 200, or some number of nodes that are each independently indexing this. Then, you’re not relying on only one organization. Now, the question is for that higher workload, what’s their incentive to do so? Sometimes the data is the incentive, right? Because they want the view into the data and they want to be able to see patterns in the data and the idea that they would be willing to run a server and have everybody notify them when they publish new data into Holochain, would be an incentive in and of itself, right?
Art: If I want to run, I don’t know, an index server for a ride sharing application because I’m a municipality and I want to see what the ride sharing needs are, what they indicate about where we may need transit routes or things like that. Having that data for us to do analysis on could actually be useful. I would have that data if I ran an index node. If you need to pay people because you don’t have useful data, data that nobody knows a use for, which I’m not sure if that exists, but, then you could create other incentives. You could run it on, like Holo Hosting and actually have people host. Host to get paid to run index nodes.
Jim: Yeah. Let’s assume that, for instance, someone wants to build a competitor to Facebook or Twitter for their community, but they’re concerned about privacy. They don’t want to send somebody to mine the data in return for providing search. Was it the application builder who creates the link to the concept of search servers?
Art: It is.
Jim: Okay.
Art: You know how we had those different Zomes or we have different microservice DNAs?
Jim: Right.
Art: The application builder can build just a little stub of a Zome that knows how to call into the other DNA to send those direct messages back and forth to the index nodes. That lets you split the work between nodes that are carrying the heavier indexing load and nodes … similar kind of thing, not just for indexing. If you wanted to run YouTube on Holochain, you probably want to have nodes that are actually serving out video, streaming video, and nodes that want to be viewing or maybe even sometimes posting video from a phone, but they don’t want to be serving video from their phone, right?
Jim: Yeah, definitely.
Art: Similar kind of thing for a different reason where you want to have break it out into two classes of nodes that are providing different levels of service and you do that by breaking it into two DNAs that know how to talk to each other in Holochain.
Jim: Okay. That tells these guys have done a lot of thinking. We know these are the hard problems in distributed computing. You’re clearly thinking about it and we will see how it goes. I think, I mentioned this originally to Ferananda that I’ve actually allocated in my schedule June and July of this year to write a Holochain app.
Art: Woohoo.
Jim: Yeah. I taught myself Rust last year in November, as my new language of the year, the year I teach myself a new computer language. I got up to the point where I could write a bit more than hello world in Rust. I’ve allocated on my calendar June and July to knock out a Holochain app just for fun. I will explore some of these issues. I’m sure I won’t go quite as far as all this. These are the kinds of things that I am interested in when I am accessing an infrastructure ecosystem for what it could really do.
Art: Nice.
Jim: I’ll probably write it up as a Medium post, which would be interesting. We are getting late here. We’ve had so much fun talking. I was going to go into validation in a major way. It’s a very important concept in Holochain as far as I’ve been able to ascertain in my readings, but could you talk a little bit about validation and how it really works? It seems like it’s actually quite central in how one thinks about designing an app.
Art: Yeah. It really is. It’s funny. Validation is a little bit of a bugaboo in apps people, right? Because often, when they’re in the early learning curve, all they’re trying to do is just make something happen like commit the data and read it back again and have other people find it and woohoo, it’s working. Now, we’re sending tweets around. One of the things I loved to show while demonstrating like the Clutter app was, we get to the validation rules and validation really is the heart of the matter. This is where peer-to-peer data integrity lives. I would show them how the edit rule on a tweet would check to make sure that you were the author of the tweet.
Art: It would compare. If I go to edit this tweet, or if I’ve submitted an edit to a tweet out there to the DHT and other nodes are validating this, they’re first checking to see, am I the author of that tweet? If I’m not, then it doesn’t pass. I don’t get to submit an update to that tweet. Only the author can update their own tweet. Then, I would go to the next section, which was delete a tweet and it just had returned true. It turns out, we weren’t validating who was deleting tweets in that app. Anybody could delete anybody’s tweets, but anybody couldn’t edit anybody’s tweet.
Art: This is the thing that creeps in as you start off by just sort of throwing a return true in the validation rules because you just want to see something happen. Then, sometimes people don’t get around to putting in all the right kind of permissions or enforcement in the validation. Actually, in the tools that Philip’s been working on. He’s calling it CRISPR because it’s for slicing and dicing Holochain DNAs. We’ve sort of abstracted basic permissions down so that we have a plugin with a roles module and you can actually create, define some different roles and then put permissions in there. We’ll even fill out some of those things for you so that you can constrain something to the author only, or to an admin group or to other roles that you might create in the system.
Art: We are trying to help people even generate their validation rules because permissions is certainly one of it. Also business logic. Do you have the credits you’re spending? We can’t help you automate that. You’re going to have to do the logic of summing the old transactions and seeing what the current balance is, for example.
Jim: Yeah. At some point, presumably like every ecosystem, there will be modules to do that for you, right? Think about the Python ecosystem.
Art: Yup.
Jim: The Python ecosystem, I use it for surprisingly large amount of stuff not because I particularly love the Python language, I think it’s okay. Because there’s a bazillion modules available to do almost anything. I think that’s going to be real important if your ecosystem is going to take off is to find reusable code that people can bootstrap up to high levels of functionality without having to write too much stuff themselves.
Art: Exactly.
Jim: It’s very important. I got a bunch of other little things here, but I want to get to the bigger picture stuff. Before I do that, one critique, in fact, I think I actually dinged you guys on a podcast back in October, I’d stumbled across Holochain last year, maybe August, somebody said, “Hey, you should check out Holochain. It looks interesting. You’d like it.” I did. I said, “Wow, this is interesting.” Then, I reached out to two of my experts on blockchain related things, distributed computing more generally.
Jim: Both of them said the same thing, which was, “They set of good ideas, but I think they killed themselves when they switched from their Go platform to their Rust platform. They lost too much time lost too much velocity, the world is going to pass them by.” How would you respond to that now, eight months later?
Art: They may have even gotten that information from one of my own blog posts where I questioned whether we really screwed that up. Because our prototype version of Holochain and Go was surprisingly functional and mature. It wasn’t built with hardened security from the outset. We didn’t really want to encourage people to run kind of enterprise level stuff on it, we kind of downplayed its readiness.
Art: Meanwhile, it worked really well. When we went to re-implement in Rust, there were a lot of hurdles. Rust is a very strict language and we were willing to bite the bullet on that because the idea is we wanted to make something more hardened and strict and that we could stand behind the security of. That spending time dealing with that strictness upfront may save you a lot of the security pains later from introducing whatever, memory leaks vulnerabilities, re-entered code, different kinds of problems that are especially challenging in distributed systems, distributed applications.
Art: There was that. There’s the kind of maturity of Rust and the Rust ecosystem and the level of tools that were available and how they kept changing under our own feet as we were trying to use them. Even worse, we tried to use WASM, or we were using WASM WebAssembly. We were compiling Rust to WebAssembly our app would run in WebAssembly. The idea being, we wanted to be able to make this in to be able to run in people’s browsers and stuff and really bring the peer-to-peer web right into browsers.
Art: We were targeting a relationship with Mozilla in that as well. Although, that hasn’t advanced very far for a lot of reasons, but we just had this idea of being able to actually run Holochain app right in your browser, and not need servers at all anymore. Boom, we’ve just made it super easy and easy to adopt.
Art: We’ve completely eliminated that threshold, that barrier that is like in the way of getting into blockchain apps and such. WASM was a black box. It created a black box but you couldn’t really debug the problems that were happening. We had memory management problems. We didn’t really even know how to manage WASM’s memory effectively. We would spawn more instances of WASM. We end up using a lot more memory than we, in retrospect now, needed to.
Art: We’ve learned a lot in this process but it was definitely a huge delay and we implemented a bunch of these things, I think, using a pattern that was kind of an anti-pattern for Holochain and that we were experimenting with running Redux as our state model in the local state system. I think that that tripped us up in a bunch of ways as well. We actually have done a reset to a whole chain state model and things are moving much faster, clearer. I would expect to see somewhere on the order of magnitude of 10,000 to 100,000 times performance increase from this refactor.
Art: I think we lost a lot of steam. We lost a lot of momentum in that process. I do regret now not actually taking the Go prototype and building more of an ecosystem around it and having instead of it being kind of the main stream track, having it be more like a skunkworks track to do the Rust refactor. Where we have come out with a more hardened version but we wouldn’t put all of our attention on that. The problem was, we wanted to build something that required the hardened security. Yeah.
Jim: Yeah. Keep in mind, as we talked about earlier, HTTP, HTML, they were just piles of shit, right? Terrible.
Art: Yeah.
Jim: They somehow managed to build a whole empire. Yeah, I guess time will tell whether that was a fatally wrong decision or not.
Art: Yeah.
Jim: Do you feel now that that is reasonable for developers to start looking at Holochain and your ecosystem to build real stuff with?
Art: I do. We haven’t actually released the refactored core yet but it will be highly compatible with the existing one, and much more performance. You can write apps now that will not need to change much to run on the refactored core. I think we’re actually ready for that. We’ve been putting it through the paces. Unfortunately, that’s also been some of our delays in launching the Holo Hosting network is really hardening Holochain before we can actually run a real hosting network on top of it.
Art: There’s these two separate projects, Holo as a hosting network and Holochain, which is just an open source, peer-to-peer DAP platform, essentially. People confuse the two a lot because people assume that Holochain has a currency, for example, it doesn’t but the Holo Hosting network does. People conflate the two.
Jim: Okay. That’s a perfect transition because that’s my next topic on my list as we kind of wrap up having talked about Holochain in moderate depth. I think enough for people to get a good sense of what it’s about. Let’s go there. As I was doing my research, I discovered, okay, we have Holochain, but we also have Holo, HoloFuel, HoloPort, et cetera. Pop up a level and talk about the ecosystem that you’re building around Holochain and the various parts and what they do.
Art: We really had a commitment to try to bring P2P computing to the mainstream. For us, that means being able to serve people right now the way they use the web, where they can click on a link or type a domain name, do a search, right? Something comes up in their browser and they don’t have to know that they’re dealing with next gen distributed tech yet.
Art: They can dip their toes in the water and use it as a thin client, where somebody else is kind of providing the pure hosting for them. Sorry, let me back up and just say Holochain doesn’t have a built-in currency because we believe that we’ve segmented the problem space in a way that you’re only carrying a load you want to carry. You’re only running an app, you want to run like we were talking about your company’s Slack app kind of thing, right?
Art: You hosting each other’s data for the 50 people in your Slack team or something like that is a minor load. You’re carrying it because you need to communicate with those people. You don’t have to carry a huge monolithic blockchain load of every other app in the ecosystem, just your own. Even that one can be sharded and broken up into smaller pieces. We believe we already solved kind of that built-in incentive problem of people running apps. The problem is, how do you bring in a mainstream user that isn’t going to install some next gen peer-to-peer crypto app?
Art: That means, they’re just going to consume it on a web browser, which means they’re not kind of sharing the load, which is the way Holochain is built. It’s built to share the load among the users. Then, that means one of these other users kind of has to take on an extra load for the web user. That’s where the Holo peer hosting network really kind of comes into being and why it came into being, is a way to be able to take this stuff really mainstream and have the experience be like you type in your email and the password and you think you’re logging in.
Art: You are sort of, what you’re really doing is using that to generate keys and you’re stepping into a world where you’re now managing your own private keys and dealing with cryptographic applications that are decentralized. We’re hiding all of that so that it just gives you the main stream experience of using a website.
Jim: Got it.
Art: I think that’s critical for this stuff to be able to go mainstream and it’s a huge industry. The whole cloud hosting industry being able to host applications on peer networks and not give all your data over to Amazon or Google or whoever it is that makes it easy for the NSA or whoever needs to come and file a subpoena to access your data. You’re still putting it all in the centralized places, even though theoretically, you control those virtual servers.
Art: They’re still under their control. This creates a way of actually having a resilient framework that the community holds itself.
Jim: Let me ask you a question. I think I know the answer based on reading the material on your websites. You described Holo as an Airbnb for Holochain apps. Does that mean that Holo itself will not actually have servers but is essentially a switching system for other people’s compute capacity or will you have some of your own servers or will it be a hybrid?
Art: Yeah. Airbnb sells more room nights or did, I don’t know what the current status of things are during pandemic. They were selling more room nights than the largest hotel chains, but never built a hotel. We believe that in the direction that things are going toward more distributed DAPs and that kind of thing, the applications, that we could host on scale massive infrastructure without ever building a data center.
Art: By being able to tap into computing power where it is just like Airbnb taps into rooms and homes and things where they already are. Does that mean we will have no servers? No. There are some infrastructure parts that are still centralized for Holo Hosting. Holochain is way completely decentralized. Holo Hosting, you still have to do things like resolve domain names, which means there has to be an authority for DNS.
Art: We have taken the centralized parts of Holo and we’re running most of those on Cloudflare’s infrastructure through their service workers and key value stores. Even those centralized parts are split across thousands of servers on Cloudflare’s 190 data centers and super performance, superfast. Because we want to, again, give us close and experience as we can to just using a website. If we can resolve the domain name quickly, route you to a host quickly, then if that host has a slightly slower connection, at least, the process of getting there was as fast as we could make it.
Art: Now, you’re getting some data served out to you from a peer host. We’re trying to make this as seamless as possible to a web browsing experience.
Jim: Okay. Let me just ask a scenario. I happen to have a couple of surprisingly fast surprisingly cheap servers I bought off eBay one time. I think, they got eight processors each and four cores each. It’s kind of crazy what they’ll do for a few hundred bucks. Could I somehow put that compute pool to work without having to worry about anything much and get paid for running my machines? Are you presumably running Holochain apps on that infrastructure? How would that work?
Art: Yeah. That’s where the currency comes in, that I mentioned earlier, is that there is an accounting system essentially for that host power. How that works is, yes, you can run that on your machines. We also sold little devices that look a little bit like Mac Minis. They’re small devices you can put on a shelf and plug into your internet router and host these things from home.
Art: The idea there was it’s kind of a plug and play system. It comes with a USB drive. You plug in, you go to a website, and basically configure your keys. That all happens locally. We don’t know anything about your keys, but you go to the website to pull down the software that writes those keys to the USB drive. You plug that into the HoloPort and boot it up and now, you have a server running on the Holo network.
Art: You could do the same thing with your boxes you bought on eBay. You don’t have to buy our hardware but you do, at this stage, have to run HoloPort OS, which is a NixOS built. That is how we’re distributing the hosting framework right now. It loads up Holochain and sets up the tools for being able to install hosted apps and all that kind of thing. The problem is that, we shipped out those HoloPorts in January and here we are in April, almost end of April, the Holo Hosting network is not publicly available yet.
Art: We’ve been still running test behind the scenes and having some performance glitches and stuff. As you may know, distributed systems are hard and debugging distributed systems is hard. We actually haven’t opened the hosting network up to the public yet. That is the intention.
Jim: Imagine some of these people have bought those HoloPorts aren’t too happy.
Art: Yeah. I imagine so. I mean, we know so.
Jim: Yeah. Presumably, they were buying them for the purpose of getting paid to host apps. Is that pretty much why they bought them?
Art: Yeah, certainly somewhere. A lot we’re really excited about the vision. I mean, we have a core community that is really excited about where we’re coming from in what we’re doing and very supportive of what we’re doing and supportive of the pure hosted web vision. Yes, it would be great to get paid in some crypto but I don’t think anybody thought I’m going to make my living off of running one little Mac Mini style device connected to my internet router. Because if you could, then everybody would do it and then…
Jim: Price would go down and you’d be making $11 cents a month, right?
Art: Exactly.
Jim: Just from my own information, because I am going to build a Holochain app. Is there some benefit to having a HoloPort to host my own app?
Art: The way that I envisioned this is that yes, you can put self-hosted apps on your own HoloPort, if you will on your HoloPort OS. The idea is that you could handshake between some of your other devices say, your laptop and your phone and your HoloPort. The HoloPort then kind of becomes your own personal secure data backup of the things that you have going on on your phone and laptop.
Art: Then, you’d have to worry if your laptop gets stolen, or your phone gets lost or drops into the toilet or whatever, right? With the key management, if it got stolen, you can revoke the keys and make a new set and pull things from your HoloPort as your own personal data backup and regenerate your state. You get what I’m saying, right? I don’t need to go on with the examples.
Jim: Right.
Art: There’s a reason to have sort of like your own little stable box that doesn’t get stolen when your backpack gets stolen or whatever.
Jim: Yeah. Got you. I got you. I could still peer with other people.
Art: Yeah.
Jim: Whether they have HoloPorts or not right, et cetera. Okay, that’s good. I think I’ll get me a HoloPort when I start playing with this stuff. Besides, you know me, I’m a hopeless techie. I always like to play with something new. Let’s go on to another topic, which I think there’s a little bit of confusion about. I’m still confused tell you the truth. What is the difference between HoloFuel which seems to be the currency for paying for Holo distributed serving capability and your hot ERC20 token?
Art: HoloFuel runs on Holochain and powers the Holo Hosting network and needs to be tuned in terms of its performance and price overhead to be able to do somewhere on the order and magnitude of millions, if not billions, of transactions a day. We’re running a hosting network. If you have, let’s say, I don’t know, 250 hosts serving your app and you have thousands of users coming in, they’re getting routed out to these different hosts.
Art: Those hosts are racking up small amounts of hosting that they sign to their hash chain, they sign an immutable log kind of record with back and forth handshakes with the Holo client that the web browser is actually using for making the request. It’s running in their little JavaScript layer that signing their requests so that you end up with a log that they can provide as proof of service essentially, that they were serving your app.
Art: That then becomes an invoice that you as an app provider instead of paying Amazon for hosting services, you’re paying this peer network for hosting services. They send in this invoice, which gives you access to the log. One of the things that, I don’t know if you’re thinking about, but you have no idea what levels of traffic are even happening on your website in a peer-hosted system, unless you have a way of collecting this data to a centralized point.
Art: The fact that they invoice you, what they do is they give you a little key that lets you collect their service log for the services. Then, you can do your fraud detection on it or whatever that you want to do to make sure that they did the work. Most importantly, it gives you the data of the activity levels and what’s happening in your app. Otherwise, how would you even know what’s happening in a peer-hosted app? You don’t have central logs anymore.
Jim: I mean, of course, we know logs are important for, go on.
Art: For tuning and troubleshooting and feedback and what people like and what they don’t and what’s working and what’s not. You need this data for a lot of things, right? Anyway, the HoloFuel is for powering that network. We need to be able to do very small transactions with low validation overhead in high volume.
Art: In other words, as you know, like you’ve railed before against the cost of Bitcoin. The cost of one Bitcoin transaction is like five American households’ worth of electricity for five days, or whatever the thing is. It’s massive. We can’t afford that cost for each one of these HoloFuel transactions. We have to build a system that is highly efficient. I don’t mean cost even in terms of a transaction fee. I just mean overall system cost because we’re doing small micro transactions.
Art: We’re tuning the currency to be a micro currency. There’s probably going to be a cap on the size of transaction you can do in HoloFuel because the validation security behind it is only sort of up to a certain level. There are certain types of attacks that if you wanted to invest a chunk of money and building a parallel computing network and that kind of thing that you could try to do on HoloFuel.
Art: If you can only do that for $1 or $10 transaction, it’s not worth spending thousands of dollars building a computing network to falsify a $10 transaction. That’s HoloFuel. The hot token was something that we did a community offering that’s a placeholder, and we’ll swap one-to-one into HoloFuel as the HoloFuel actually goes into its beta launch. The whole hosting network goes into its beta launch.
Art: Those are the two different things. Holo token is an ERC20 token that lives out there on exchanges and is the temporary thing. As you mentioned in that other project has attracted a lot of people that love or hate us, depending on whether the market is up or the market is down. I don’t think that’s our core community as much.
Jim: Yeah. Literally, you’re going to do a one-to-one exchange when the HoloFuel goes live. Anyone can convert a hot token to a one HoloFuel token?
Art: Yeah. There’s going to be a swap window, at least a six month period where it’s a one-to-one redemption.
Jim: Okay. Now, interestingly, at least in my view, I’m having some thought about this at least a little bit, you may want to think differently about things like price stability on something like HoloFuel versus a typical ERC20 token, which is, frankly, mostly speculative. Have you thought about how you want the price of HoloFuel to vary over time? Do you want to be stable, deflationary, inflationary? Do you have a view about that? Or I think you do, you’ve designed 100 currencies. I imagine you have a view about that.
Art: Yeah. As you know, I’m a currency geek and part of what we were setting out to deal with HoloFuel is to provide some healthy examples to the … honestly, what I view is unhealthy speculative patterns that are out there. The kind of sort of tokenomics people have gotten in their head of just you create a bunch of stuff and try to then kind of hype it into people believing it has value.
Art: Then, some people get burned and some people get rich. It’s not a very safe space for mainstream business to operate, though. If I accept payment this week, and the bottom might fall out 50% and I can’t pay my rent next week in it. That’s a problem for most businesses that are not in the speculation game, that are not in the speculation business.
Art: HoloFuel is designed to be anti-volatile. I would say value stable but people then think stable coin. Now, they think it’s fixed to an external currency. It’s not fixed to an external currency but it’s driven by feedback loops based on the cost of providing hosting that the hosts have and there’s real costs, electricity, bandwidth, hardware. That’s going to create a real operating range for which the HoloFuel pricing is driven by. I don’t know if you really want to get into all of the currency dynamics here, but it’s definitely designed to be a very different kind of currency than the norm.
Jim: Yeah. Okay, that’s good. I think that’s probably a good place to wrap this up. I still have some other things to talk about and frankly, I’m a currency geek too. Actually, I’ve spent eight years studying alternative currencies and actually designed a couple. I’d love to have you back on sometime just to talk about currency. Would you like to do that?
Art: I love to do that?
Jim: Okay. We’ll do it.
Art: Maybe that’s also the space for Ferananda to be more included in the conversation.
Jim: Yeah. I’m sorry, Ferananda. We kind of geek out a little bit more than I thought we might. Hey, that’s the way it goes. That’s what I like about podcasts. They are what they are.
Ferananda: I know. It was great. We went really deep into great questions. The flow was really beautiful. I got highly entertained.
Jim: Thank you for being an entertained audience. Hopefully, our actual audience will be as well-entertained. Thank you both, Art and Ferananda, for which I think will be a very interesting episode.
Art: Awesome. Thanks, Jim.
Production services and audio editing by Jared Janes Consulting. Music by Tom Muller modernspacemusic.com.