Joe Petrowski: 00:22 Welcome to Relay Chain, a podcast produced by Parity Technologies where we discuss all things Substrate, Polkadot, and Web3. Patrick and Amber, welcome to Relay Chain. We're here to talk about Clovyr, and you guys are mostly like a devops company, right? Patrick Nielsen: 00:31 I would say the thing we're working on right now is very devops-y, yes. Amber Baldet: 00:37 Yeah. It's difficult to present a kind of larger idea to folks and you can really only build kind of one thing at a time. I think when we talk about tools that are missing from this space, whether you're talking about the decentralized web or blockchain specifically, right now it's certainly developer tooling and usability. We're trying to cross verticals from the public side and public chains across enterprise, and then we talk about connecting people to applications and discoverability, and building enterprise applications, and it gets very, very massive very fast. It's a lot easier to simply say yeah, it's a devops tool. Joe Petrowski: 01:18 You guys had a really awesome talk at Trail of Bits where you talked about how crypto advances are only really useful if people have an easy way to use them. And I'm totally shilling this talk. It was really good. Amber Baldet: 01:29 That was at Empire Hacking, yeah. Joe Petrowski: 01:31 Okay. It was part of a Trail of Bits program. Amber Baldet: 01:33 Yeah, yeah. They sponsored. Joe Petrowski: 01:35 Okay. Your mission is really to find the best tools and connect them to the application developer so they don't really have to deal with blockchain and ideally the end user doesn't even know that he or she is using a blockchain. So, it sounds like this kind of massive gap in the space. What interested you or motivated you to work on this problem? Amber Baldet: 01:52 That talk came out of one of Patrick's better rants that is recurring across several of our talks, including I think Web3 probably did a good rendition of that last year as well you could talk about. But this idea, we both have dealt with security kind of community ethos of saying, "Why don't people think like us more? Why don't people know how to use these tools?" We built something pure and wonderful and my next tool is the most purest thing I've ever seen. And then wondering why everyone else in the world isn't automatically converted. And that same kind of philosophy I think happens a lot in the blockchain space as well. Probably not least because there's a lot of crossover in talent and skill set, and people even at this point, which is great. Amber Baldet: 02:39 But yeah, it can be easy to think that because what you've created works for you that other people will see the workflow and the usability as the same way that you do when really we're dealing with an extremely long tale of people that not only aren't interested in that or don't want to learn about it, and that's not because they're not good people or not because they're not smart enough, but because they have other deep areas of expertise that we don't know about. So, we can't really be subject to our own blind spots. So, we need to build tools that are super simple and that can have a much wider reach. Patrick Nielsen: 03:14 If you look at the whole blockchain space right now, what people have been working on is primarily protocol work and that's obviously very fundamental and important to get right, but the people who are interested in that are mainly other protocol developers and people who can appreciate whitepapers and stuff like that. Not people who are just looking to download and app and use it for something. And there's a huge space there. And some of that is devops, but it's also just a lot of, I wouldn't say boring, but certainly a lot of different little pieces that have to be glued together. And one of the things we've discovered in the last year is that there are probably five times as many things as what we assumed at the outset, but what we're working on now is something that hopefully the protocol developers will be able to plug into to get some of that for free. Patrick Nielsen: 04:09 And that's another one of the things that's a little bit frustrating about the space is that since everything is so economically incentivized to work their own tokens, there's a lot of work that could be repurposed for other projects or could be a little more generic or abstract but isn't. So, we're trying to build something that's not completely abstract, but abstract enough that it's applicable to different projects. So, one of the first things that we supported out of the gate was Ethereum, which includes Parity Ethereum and Go Ethereum and other Ethereum clients. Joe Petrowski: 04:40 When you say supported, what do you mean? Like that you can configure a node and have a binary for that? What does support mean for you guys? Patrick Nielsen: 04:49 Basically there's a config that maps to the different configs for the different Ethereum clients, and then there's obviously the Web3 API or Web3 RPC API, which is not Web3, but the things that they do have in common, we simply just bridged to that. And then the things that they don't really have in common, we have a few things where we have stepped out an API to try to remove that difference. Joe Petrowski: 05:14 Yes, I think a lot of things that we value in the space as protocol developers, that something's open-source and you can go build it yourself. A lot of people actually want a black box. We kind of criticize closed-source software or Windows or whatever because you can't go see the code, but most people, they want like, "This is the API, I want to be able to call these functions or do these things." And it seems like what you guys are building is like you can turn this into a black box, but you can also go see what's in it if you really want to, you just don't have to. It just makes it a lot easier to work with it. Patrick Nielsen: 05:44 Yeah, pretty much. Because there are so many parts involved, like one example is Ethereum clients are just static binaries in most cases. And even though they're static binaries and those are easy to support, there's a lot of work that can go into making it very easy for somebody to self-run a binary if they do not know a terminal or have VPS somewhere. And it's very easy to get trapped in the process of building something for that where it's just 100x easier to centralize a primary aspect of it, because then you can just take care of that. It's much more difficult if you want the whole thing to be decentralized. So, that's a large part of that work is making protocol developers able to say, "Here's a config for my project," and then have that work taken care of in a way where Clovyr is not suddenly a centralized party that's gatekeeping access to anything. Patrick Nielsen: 06:39 And that does look like a black box for the user, but it isn't for the protocol developers who want to know, "What is this stuff that's running my application?" Amber Baldet: 06:49 Yeah. There's a big difference between saying, "Oh, this is a one click install for someone who wants to run an application that pops up a GUI for them and that's the only thing they see," but they've actually silently and seamlessly deployed some infrastructure behind the scenes that they truly have no intention of ever touching or updating or maintaining themselves and something that's a one click deploy for someone that was trying to get to the point where they have a development environment where they can build something. Those were two very different things and right now we're starting to see more projects that are saying, "Oh, one click install. One click deploy." And then there's a 19 minute how to video on how to use your one click tool. Amber Baldet: 07:26 And the comments on one of these YouTube videos is just like, "Well, that was a lot more than one click." Which is true. It's very hard, because you have to make choices for people to remove those clicks, and that can mean a reduction in their power, their agency, their choice and you don't want to do that. But at the same time, 99% of people don't change defaults. So, how do you find that kind of balance and expose the underlying power to the people when they're looking for it, but make sure that the people that are not get a good experience that hasn't say, made a choice that opted them into something that was, say undermining their privacy or something. Joe Petrowski: 08:03 You gave me a thought that I'm having trouble articulating. But giving people the tools that if they really want to tweak the individual settings they can, but still the default settings on these tools might be better than what they have now. So, we shouldn't stop them from using the default settings of these new tools just because they can't go through all of the little tweaks. Amber Baldet: 08:25 Yeah. And even in the developer space, when you go to change some of the configuration settings, now where someone has built an interface to do so, they'll have a field that says coin or something, and there's no description. And you hover over it and the tool tip is like, "Coin". Like what am I supposed to put in this field? So, it's not even fair to do something like that to your users. We need to take time to not only have quality documentation and have things that run seamlessly, but where when you are exploring what happens if I change this setting, you don't want people to be scared. Because then again, they won't change a setting that they're afraid is going to break their entire install. Amber Baldet: 09:07 And that takes work and it takes thinking like your user, and that's all just part of that kind of user-centered design process. Patrick Nielsen: 09:13 Right. And that's one way in which we're not really a devops company because devops is not some holy grail or something. The state of the art in devops is something that is configurable via environment variables, like 12 factor apps. That's pretty much the pinnacle of devops. And if you don't know what the environment variables do, you're stuck. And that invariably means reading a bunch of documentation and experimenting, and getting feedback on whether this worked or not. And when it finally works, you assume that everything's fine. And that's not really a great user experience for somebody that doesn't have, that's kind of like the Gen 2 Linux of deploying binaries of today. Yeah, there's a lot of work there to make that more than just a bunch of key value maps of strings. Amber Baldet: 09:59 Yeah. I'd say one more thing on this is that even protocol developers probably have not run their own copper wiring for their house, but you expect the lights to turn on when you flip the switch, right? So, once something is sufficiently distributed and commoditized, we just assume that it's always there and is this kind of underlying fabric that we just use. But at the same time, there's this whole resurgence of the maker movement where people wanted to go and learn how to solder. And if you are so lucky as to not be exposed to many blue collar jobs, you think it's super cool to be part of the maker community and learn how to solder. But that's also like an entire vocational career, and there are still people who do this. Amber Baldet: 10:37 So, I think that as blockchain technology and a lot of these different protocols that we're developing now become much more ubiquitous, it'll become ever more novel to interface with them so directly. We'll see more and more and more types of abstractions and there will always be a subset of people that are just really interested in getting under the hood. Some of whom that will be part of their job, some of whom it will be just a wonderful part of their hobby. And some day it will be like, "We really need a HAM radio operator in case everything else goes down and you're very valuable to society, because we don't even know how this works anymore." But we're not there yet. Joe Petrowski: 11:11 Far from it. But hopefully you guys are laying the steps to get there. Amber Baldet: 11:15 Hopefully. Joe Petrowski: 11:16 I was at the Web3 Summit last year. Patrick, you presented and you had this slide where you talked about four factors that kind of govern this development and it was politics, business models, developer experience, and end user experience. So, if we could just talk about a little bit of each of those and how you see them. So like if we start with politics, a lot of with the Web3 or what you call The Webbernext (https://youtu.be/KS_RY9y0g_w?t=588), it's this idea that like the Internet is its own jurisdiction. So, it's not just ... Right now it's kind of like the EU has its own laws, the US has its own laws, China has its own laws, and this Web3 has its own jurisdiction and-- Patrick Nielsen: 11:52 That used to be the JP Barlow interpretation of the Internet, yes. Joe Petrowski: 11:55 Yeah, sure. Patrick Nielsen: 11:57 That is the utopian, idealistic dream of what the Internet could be. In practice, that's not really what it looks like. Fundamentally, the Internet is routed at a packet level by machines that are controlled by nation states, and those nation states make decisions, and increasingly in the last decade or two, there has been a return to something like the '90s crypto wars where people in different geographical regions had their own cryptography and they told each other to only use their region's crypto and don't give anybody else it. Kind of seeing the same thing with the Internet now. It's just much more soft and subtle. It's just apps that only work in certain places and/or are censored in certain places. Invariably, it leads to different information pockets. Patrick Nielsen: 12:49 I hope there can be something like a Web3 without borders, but certainly the Internet as a whole is not really going in that direction. I guess it's kind of up to us to try to prevent some of those tendencies. Amber Baldet: 13:04 Yeah. And it's possible to reach across these borders and jurisdictions like never before to interface with people or access information, or now to engage in commerce directly. But that doesn't abdicate you from the local laws where you live and someone can still come to your house physically and remove you for having done something in cyberspace. So, we have to be careful when we think about what you can do and what is possible, especially in censorship-resistant systems, and what the repercussions are if it is known what you have done. Amber Baldet: 13:34 In a similar way to the free speech argument, you might be able to say whatever you want, but that doesn't exempt you from consequences for what you have said. Joe Petrowski: 13:42 Sure. So, how do you see these things interfacing like, yeah that's certainly not the Internet that we have now, but if some of the tools are to push it in that direction where the Internet does have some of its own governance that's ungovernable by a law that's on a piece of paper, how do you see that playing out and what protections need to be in place, kind of on both sides. Amber Baldet: 14:05 Are we specifically talking about on-chain governance or are we simply talking about governance of digital systems in general here? Joe Petrowski: 14:09 In general. Amber Baldet: 14:10 In general. I think it's very interesting and hopefully promising to be able to have better records of what people intended to happen and to be able to better arbitrate and have better evidence or underlying information in order to prove or disprove that something happened, whether we're talking about logs or zero knowledge attestations, either side of that. But at the same time, the dispute resolution framework systems that we use in the kind of traditional legal system are fuzzy intentionally to allow for differing interpretations and the evolution, especially of social interpretation, of what these things should mean. And we redefine them over time. Amber Baldet: 14:50 There's a very different implication when we talk about something that is deterministic and should always deliver the exact same result every time and something that is intentionally fuzzy so that it grows and changes with us. And the interface between those two things, let alone the physical enforcement of an action, maybe not just say removing your coins, but like we're going to remove you, enforcing that is a very different thing. And at the end of the day, where people are talking about, "Oh, we're going to put our land titles on the blockchain or something," the person who owns the land right now is still the person who can put a tank on your property and say, "I own this land." So, I don't see how a digital record that something should have been different abdicates us from the physical enforcement of that system. Was that really dystopian and sad? Sorry. Joe Petrowski: 15:39 A little bit. But it's something that I think we should probably talk about more and take more seriously. Patrick Nielsen: 15:45 I think right now the state that we're at is these kinds of technologies kind of make things or have the potential to make things more robust in the cases where simply incompetence and systems that don't function well would have allowed for certain problems to arise in the past, like something like land ownership. That prevents possibly low level corruption and low level power. Amber Baldet: 16:07 Or trickiness. Patrick Nielsen: 16:09 Yeah. And that kind of fuzziness. There's a certain sense of naivety that we're just going to build a technology and as long as it's like formal methods-y enough, then the governments of the world are just going to listen to the math. That's not really historically how it's worked out, like Amber said. A tank is going to roll onto your yard and then you're hiding from bullets. That's not really something a blockchain can prevent. Joe Petrowski: 16:35 Yeah, I think this kind of goes with the cliché, with great power comes great responsibility. And these tools give individuals a lot of power. And if you're not really aware of the power that you have with these tools, there are other people with physical power and you need to be cognizant of that. Amber Baldet: 16:51 It does offer the opportunity, though, definitely to step outside of the confines of the current system and do something different, whether that's hoarding tokens that you believe will have value under some future circumstance or keeping records for yourself, or even just publishing a hash of something that you want to disclose and prove really happened later. All of those things have value. We just need to be realistic about under what circumstances and to what end. Joe Petrowski: 17:23 If we move away from dystopia, something I believe- Amber Baldet: 17:23 I think we were just talking about current reality, but yeah. Joe Petrowski: 17:27 Toward something I think are more optimistic about, business models. And I think you've said in some talks that you've seen some promising non-surveillance models. What kind of progress do you see and any good ideas? Amber Baldet: 17:40 It's totally possible to build technical tools or non technical tools that have a business model or they make money without being driven by surveillance. Before the last 15 years, I would say all of our business models were kind of that way. I mean, all of the software that was sold, besides the spyware that installed itself on your system in the '90s from Kazaa or whatever, it was totally feasible to purchase and run software without it being subsidized by advertising or being spyware dependent. We're seeing people postulate different kinds of just regular subscription models or opting into tiered kind of models where different access to different information might have different pricing levels. But what we talk about there is consensual data assignment or sharing, and the confidentiality of said data. And that's a different conversation then when we just talk about straight up privacy, what I have no one else should be able to see. Amber Baldet: 18:38 And right now I feel like there's a bit of a conflation in the public discourse about trying to keep everything that you have private. Like this will only be on some local chip that I have and I'm never going to send this data anywhere. And that is really complex. There's not really a lot of real applications that can make use of that, bring the application to the data, perform a bunch of operations over encrypted data, send kind of results back. That's not really happening in production right now, so what is more viable, near term kind of business models are minimal data sharing. And using that data in a responsible way, having better, more clear legal covenants with your customer base. Being more transparent about how that data is used, and then interfacing with kind of the changing regulatory scheme about what you do with your customer's data, the third party data brokering, etc. Patrick Nielsen: 19:30 One thing I think is really interesting is ad tech, which obviously is kind of the frontier of surveillance capitalism, because it is about data sharing and data sharing about everybody, and as much data as you could possibly gather. And the US in particular has no particular enforcement of how that is done and all the companies just share all the data with each other. But in the last 10 years or so, it's become difficult for CEOs and boards to excuse doing this so rampantly, because they can actually be fired now and be held accountable. Patrick Nielsen: 20:02 I think the famous example of when this started was when the Target CEO stepped down because of a data breach. And before then, data breaches were a chief security officer thing. You can let them go, let the CIO go, but the CEO, they were handling bigger things and they weren't really accountable for that. And that totally changed in the last decade or so. So it's in the corporation's interest to not have that risk. And at the same time, cryptography has received this thunder strike of funding from blockchain related efforts which has led to a lot of advancements and multi party compute for example is now possible to run algorithms on different computers that can compute results that give the CEO what they needed to sell more product or whatever it is. But without collecting, "This person prefers that movie" or whatever. Patrick Nielsen: 20:57 It's interesting that all these things are happening at the same time and blockchain, or consensus technology is just a way, if you think about it, to coordinate those kinds of tasks. And I think there's a lot of business models there that have yet to be realized, but they're very applicable. Joe Petrowski: 21:14 Yeah. And this sounds like going on what you said, Amber. People don't want to keep everything secret. It's nice to turn on your phone and tell you like what the weather is where you are today. It's nice that somebody knows that and can give you information that's pertinent to you. The problem is more like how it gets used after that. It's not just like the first person you give it to. It's who they give it to. Patrick Nielsen: 21:34 That's one of the interesting that's GDPR did, is make you as a company have to be more explicit about who you then give the data to, because that is the most opaque thing. And especially in US ad tech, it's very incestuous, for lack of a better word. They just give the data to everybody else and then they give it to everybody else, so inevitably, everybody has all the same data. Now at least companies in Europe or that have customers in Europe have to be explicit about who the next people in the chain is. Joe Petrowski: 22:04 Do you think it's useful or healthy to enforce this in geopolitical ways versus protocol ways? Or do you think we should be more focused on protocol development to just prevent this from happening in the first place? Amber Baldet: 22:18 I mean, I'd like to see DRM software that actually worked ever. Once the data has left you, the data is generally not able to be clawed back. Again, to what Patrick was saying, there are ways to work around that now with some of the different advances in multi party compute and other things, but I think GDPR was an interesting start, but definitely postulated as always the technology regulation is backwards looking. They're just trying to catch up with the idea of a cloud where all the data in the world, you can pull something off the Internet by contacting a small number of companies. And that is radically changing. Of course, it never was actually true in practice because you could mirror anything. But the more decentralized, again for lack of a better word, the Internet is, then regulation like that really falls apart very quickly. Amber Baldet: 23:08 It would be great to have other sorts of enforcement or even location mechanisms or intellectual property or compensation. You have to trust the person on the other end of the wire or you simply can't use an application. Patrick Nielsen: 23:21 Data sharing as a technical problem is incredibly difficult, because how are you going to prevent somebody from copying it? Joe Petrowski: 23:27 Yeah. If we move on to developer experience, the first question I have is like, which developer? Because I know in my experience, from previously engineering and now I'm at Parity, but like protocol development versus application developments is very different. So, who are you looking at here as the developer you're targeting? Patrick Nielsen: 23:49 And I would say there's another kind of developer, and that's the developer who so far has not cared about blockchain because they think it's a bunch of hype and they don't really understand what the properties are that you could get and how those are applicable and the kinds of things that they're building. There's a huge market there for people who so far have been uninterested. I think that's much less in the last several years and it helps to come out of kind of blockchain winter, having tools that do more things rather than just a bunch of white papers and people being very excited about stuff. But the blockchain space I still think has this very money and hype driven thing that scares a lot of developers away. Patrick Nielsen: 24:31 I think possibly the most important developer experience is the one where you kind of decompose some of these huge things that have been built into little building blocks that a regular developer can understand. For example, consensus. If the only problem you have is you have to coordinate some basic algorithm between a bunch of servers and you want to have a system where one malicious server can't corrupt the whole thing, why isn't that a library rather than something that is built into these large ecosystems where now you have to adopt the coin and pay with stuff? Of course, cryptoeconomic incentives are important. But I think there's a huge amount of work to just kind of make, decouple these abstractions from all the different projects. Patrick Nielsen: 25:17 And Tendermint is one example I think of ... Tendermint and Polkadot are two examples of projects that have come or are coming quite close to being these kind of general purpose tools that you could pick up. IPFS is another one. Joe Petrowski: 25:33 Yeah. We've, at least in Substrate and Polkadot, we've completely separated consensus from tokens. Actually, we've kind of split consensus into like block production and finality and separate modules. Neither of them even know about tokens. It's completely separate. So, how do you handle protocol shuffles like Tendermints, Polkadots, Ethereum? These protocols keep changing. So, how do you build libraries of tools that can give higher level developers the same APIs that they want without having to worry about, "Okay, what's the next consensus thing that's going to come along"? Patrick Nielsen: 26:08 Yeah. Great question. So far the way that we've been doing it is treating the underlying protocols as key value stores, plus plus. So, using the properties that we're sure will stick around. But it's a great question. I don't have the answer to it. How do you make something that withstands major protocol changes? You can't really. And yeah, that's true for everything, right? It's just a matter of time until we can ... we have something where major protocol changes aren't necessary. Amber Baldet: 26:42 It's also a challenge for us in that we've said we are "blockchain agnostic", for whatever that means. But what that means is that we're not just part of a single community that's hoping for the success of one single project or one single token, but rather are focusing on higher order goal of helping people be able to do something that they can't do right now. And whatever thing it is that helps them get that there, it is useful for us to support. Early on, that means keeping up with a relatively small number of leaders, but it also means constantly watching some of these emerging projects that don't necessarily have the technical baggage and have learned from seeing the other kind of leader projects that come to disrupt. And then making sure that what we have, it's not dependent on Clovyr to build the thing for everybody to interface with, that we can make something that's extensible and that other people can onboard themselves, and that there's not a gatekeeping system. Amber Baldet: 27:40 And that means that if this becomes the de facto way to say, deploy or make something accessible, that teams will bake that into their initial roadmap and they'll help keep up with us and help us scale in a way that we couldn't do if it was just based on our own kind of relationships and partnerships. Or perception of where the market is going. Joe Petrowski: 27:59 Yeah. For the final end user, how do you view this technology compared to Web2 technology? What are the things that will be inherently better for the user and then what are some of the challenges with decentralized tech in creating a good user experience? Amber Baldet: 28:16 I think that when we look at people that are coming onto the Internet or are growing up on the Internet these days, they are different. They use technology differently than prior generations. So, we are always ... I don't mean we us. I mean all of us collectively have to be designing for both people at large for whom technology is always going to be foreign to them because they are older than us, and also people that are younger than us that are so indoctrinated that they see the Internet as the light switch and they weren't here when it came on, and they have this idea of personal branding and selling a product that is themselves or from their Instagram feed. That's not something that was around when even I was a kid. Amber Baldet: 28:58 So, thinking about not just the sharing economy, but the gig economy, but this coming very personal economy, I think it's an amazing opportunity for us to decompose the things that make a business into something that an individual who does not have an MBA is able to create and run, and the accounting is abstracted for them. The legal entity is abstracted for them. The payments processing, merchant services. Somebody selling soaps they made at home is not like, "Oh, let me figure out who my merchant payment processing treasury service solution is." So, how can we make that so micro and so abstracted for them that they focus on what it is that they're good at and the rest kind of flows behind it? Amber Baldet: 29:42 And when that is seamless to them and they can focus on the cool thing they want to deliver to the world, and they can do it peer-to-peer with somebody who also is like, "Hey, I wanted that thing and I could discover that thing that you're selling without having to go to the one world store that we now have, the singular centralized storefront of everything in the future, but rather discover it like I was walking through somebody's neighborhood and seeing their farmers' market kind of shops," that is when we'll have like an amazing kind of integration of this local marketplace that thinks like a global digitized marketplace. So, building the tools to enable that I think is really, really promising and exciting. Patrick Nielsen: 30:20 I'm reminded of one of my favorite Twitter profiles, John Backus (@backus). He constantly is reminding people that decentralization did not start with blockchain and didn't start with Web3 or any of these things. In fact, many people have tried and without coins and failed in the past. And of course, Linux and Unix has its own mantra of the cathedral versus the bazaar. It's very easy, but there's a lot of inefficiencies in the cathedral, but the bazaar kind of decentralizes things and people build their own tools and pick the tools that they want to use for themselves. But the problem that I think this space has that it does not have an answer to yet is, like Amber said, the people building their personal brands. How do you build something where even with the hurdle of having to now use, having transaction costs, how do you build something where somebody can build their personal brand on it. Patrick Nielsen: 31:20 And if you look at every crypto project, they don't know either, because they're using Medium to host their blogs. So, before we solve that problem, there's just not going to be that many of those that it's super important. But that's the piece of the protocol work stuff that's not ... If I were to base it on John Backus' sober thoughts, it is something that may never be solved, like the identity problem. It's not like we just need to put enough minds on it for a long enough time. That may be just not possible. Amber Baldet: 31:55 It's the difficulty, though, with saying, talking about the Internet or The Webbernext or Web3 and then saying, "Who is your user" is that your user is everybody. And so you can take this small slice and say, "How could we make this different for kids who are trying to sell something on Instagram?" And that's a lot of people. And you could definitely build a successful business doing that. But it's one very, very small slice of a global population. So, if you're looking at the half of the human population coming online in the emerging economies over the next 10 years, they have different needs. So, figuring out how those same tools can solve different purposes without us having to build completely separate tooling that doesn't speak with itself, that's a challenge. And then we move to small business that has a different challenge from startups that are trying to scale quickly or from enterprise that has legacy infrastructure. Amber Baldet: 32:43 So, trying to build something that works for absolutely everybody probably only happens when you talk about something as tiny and as small as like network communication protocol, right? But when we talk about what solves a problem for an end user, it is a much more full fledged kind of vertical stack of things. So, how can we compose things together so that you can solve either end of that spectrum? I think we'll have as robust a tool kit as you do right now when you go out to build a web app and you can look at the evolution of everything, of how those kind of stacks have evolved. But we're now seeing this kind of convergence that you might pick up the same tool to solve your own problem at home as you would in a larger business. And businesses, in order to stay nimble and agile are importing these tools and importing developers who don't have a 30-year history of working in Java exclusively, for example, right? It's changing very quickly and I can only imagine that that will continue to decompose more. Joe Petrowski: 33:42 Yeah. Speaking of like developing these tools, Amber, you said something that I really liked. You said decentralization is not a network topology, it's an ongoing process. Amber Baldet: 33:52 Did I say that? That sounds great. Joe Petrowski: 33:53 You did say that. Amber Baldet: 33:53 Cool. Okay. Joe Petrowski: 33:54 I can find the YouTube link for you, if you want to have the source. Amber Baldet: 33:59 I believe you. Joe Petrowski: 34:01 How do you think about this process compared to maybe other software development or just general engineering processes? Amber Baldet: 34:07 In that specific instance, what we're talking about is that in this arena, people get very attached to this idea of decentralization does equal your network topology, right? It's where are the nodes, who's running these things. But there's so many more inputs. This is, Patrick and I gave a talk at Devcon I think last year that kind of tried to enumerate the many different layers of where you have these kind of soft power aggregation centers, even when we're talking about decentralized systems, let alone kind of everything else out in the world. But everything from kind of who are your developer inputs, who actually of course has maintainer access to your code, but when you have questions or are developing new features, who do you ask for input. How diverse is your community that is giving you input? Do you only accept input via GitHub pull requests? That's even limiting, right? Amber Baldet: 34:57 So, what can you do to have the broadest base, the widest funnel? And then if we all decide that there's only a single privacy solution and it's a hardware chip from a corporation that is incentivizing or subsidizing people to test it, do we all end up using the same thing? And again, now we're all dependent on one thing that might have a vulnerability that's discovered later. So, decentralization allows you to inoculate yourself against kind of failures of any one part of the system, and so at each step we simply have to be asking ourselves who is it that we are becoming dependent on here. And I don't believe that it has to be that full decentralization, whatever that means in whatever capacity, is a goal or necessarily a good thing, and it certainly slows things down. Amber Baldet: 35:43 It slows down consensus not just of your network, but of figuring out what do we do here. Because if you're asking more people and taking in more opinions and evaluating a wider number of solutions, then it takes longer to figure out how to move forward. But hopefully you end up with a more kind of robust and resilient system that can keep going in a variety of different types of adverse environments. You just need to determine whether or not the thing that you're attempting to build has the kind of threat model that it needs to run in such adverse environments, because a lot of times there's so much over-engineering that it slows you down to the point where somebody else from behind had a small team that solved one problem, it does one thing, and one sort of condition, they just rocket out ahead of you and all of a sudden get all of the market share. Joe Petrowski: 36:29 Yeah. So, for privacy systems, privacy often gets kind of framed at the edges, either you shouldn't have any expectation of privacy or you should have expectation of complete privacy, and so how do you see the evolution of privacy tech? I know you've talked about some of the tooling before, but how do you see that evolving now? Amber Baldet: 36:49 People are more and more interested in understanding privacy tooling, but they are still reticent to use tools that are specifically geared at "solving privacy problems". Most people are not going to run their Internet over Tor. Most people are not, most people don't even use a password manager, even though it's a very simple kind of thing to use to make yourself more secure. So, the more that we can do to make people not have to go out and seek privacy tools, but rather have them seamlessly integrated into the applications that they use, the better off we are. That's much easier said than done and that goes back to what Patrick was saying earlier about making security tooling or privacy tooling easy for developers to access and use and very good quality tools simpler to interface with. Patrick Nielsen: 37:37 One of my favorite examples is one that we gave in one of the talks that you referred to, is the question which thing is more important, Signal the private messenger, or the fact that WhatsApp adopted the double ratchet, the same kind of double ratchet scheme? And there is not really a simple answer to that. They're both very important. But if you just look at the number of users that benefit from either one, there's a billion users of WhatsApp versus, what was it- Amber Baldet: 38:08 Five million. Patrick Nielsen: 38:09 Five million for Signal. So, everything is relative in that sense and oftentimes the purest things have the fewest users. So, a lot of the work that's not so fun is balancing out all these impurities and trying to select impurities that are not going to hurt people. And so there's no simple answer to what it means to kind of have privacy, but certainly it's possible to do something that prevents something like dragnet surveillance in popular applications. Amber Baldet: 38:41 Yeah. It is important to look at, though, what teams are creating these things and to understand where software is coming from, even when we talk about the WhatsApp to Signal kind of comparison, we know that the team behind Signal is committed to privacy as a product, although they're selling it as not even ephemeral messaging anymore. They're selling it under a totally different kind of marketing purview, but that they've made technical decisions that will continue to kind of support a specific type of user. In the WhatsApp case, it's a smaller ... a larger user base, but with a smaller thing that makes it a private messenger. And then they've made business decisions by integrating with say Facebook and Instagram that now have put them in the position of being part of this whirlwind of what's happening with privacy at Facebook and say monetizing an originally end-to-end encrypted product and how does that fit into the Libra Coin or whatever that program is going to be. Amber Baldet: 39:41 So, there's a lot of uncertainty there, because the team and the philosophy behind it is now larger, but also it's more obfuscated, kind of who's in charge and whom they're serving. Joe Petrowski: 39:53 Yeah. I saw an interesting stat in Mary Meeker's Internet report last week that people who care about privacy from 2014 to now actually decreased from 64% to 52%, but the amount of encrypted web traffic increased from like 50% to 90%. And so I think that shows the tooling is working and people aren't really going to take the extra steps to do something to protect their privacy. But developers can put these things in the infrastructure. Patrick Nielsen: 40:20 Yeah. And I think that's one of the most self-defeating kind of recurring arguments in the space, is this notion that technologists are supposed to be neutral and that if we just build these governance solutions, then people are going to come along of all different shapes and sizes and we're going to make these decisions totally democratically. And oftentimes the people saying that are people with very sensible opinions that could make good choices on behalf of other users. But they defer that responsibility out of a sense of it not being right for them to make those decisions. But somebody else is going to come along who is not as ... Amber Baldet: 41:01 Altruistic? Patrick Nielsen: 41:03 I was looking for- Amber Baldet: 41:04 Pragmatic. Patrick Nielsen: 41:04 Who is more evil than that. And they're going to make the choices for you. So, yeah. I kind of like the idea of Linux as, or open source in general of these kind of distributed or decentralized dictatorships of where each project has a small-ish number of people and they all make decisions about how their project should work, and if you're unhappy with it, then you can take your own small team and fork it and make another thing. But that's possible and it's obvious that it's possible to compile these into things, Linux distributions that work on a massive scale and that have commercial value. But we're kind of in the early Linux stage of Web3 where people are still out building all these things, but there's nothing equivalent to a Linux distribution and certainly not many of them that people can like jump between and have a common language for that. Joe Petrowski: 42:02 Yeah. All that comes down to defaults, I think. Right now some of those people who do care about privacy might not have the technical know-how to protect themselves, and so the default is no privacy, but if we can build the tools, it becomes up to you to opt out, like if you don't want privacy, then use something that doesn't protect your privacy. Patrick Nielsen: 42:21 I think it's incredibly important for the people writing the software to enable those things and then make them opt out, yeah, instead of opt in. Joe Petrowski: 42:28 I want to turn away from Clovyr and current tech and a little bit more towards like career advice type things. You guys both came from JP Morgan. And I think something you did that's really cool is that you started this Quorum program (https://github.com/jpmorganchase/quorum) from inside. It's kind of like starting a business from within a very large business, and I've worked in a very big organization before, or like big corporation, and then tried to go out on my own, and just didn't really have the know-how, and I got completely lost. So, with blockchain growing and people hiring, for people that end up in the big corporation that's interested in this, how can they stay entrepreneurial and creative and develop new things? Or just stay ... I think a lot of it is like being aware, of seeing the opportunity, but what are some tips you have for seeing that? Amber Baldet: 43:16 Well, I had not worked in startups previously by choice, because I actually prefer the legal protections of working in a large organization that has a functioning HR department. Patrick has a different experience. But I think that it's great for people coming out of school to go work in a larger institution so that they can understand the things that it takes to make a business run, and this has nothing to do with JP Morgan or that specific program, but understanding the different types of job functions and roles and how they come together in a large place. You see a lot more than the kind of bare bones things that can come together in a startup that just so happened to maybe some times get a product out to production. But in a well-oiled machine, you can understand how legal can interface with different types of billing systems and business development, and how sales might be different than biz dev, it might be different than internal product management, and how product manager's not a project manager and what like a very large kind of technical team can come together to do. Amber Baldet: 44:19 So, then you can kind of do something on a small scale, I guess. Which isn't to say, I think what we had an opportunity to do at JP was a little different and they did create an actual kind of, it felt like an internal startup incubator, kind of new product development team, and the goal of that was to create a place where things could kind of spin out and become their own entities. It just so happened that Patrick and I were aligned in the types of problems that we wanted to solve and I don't think that so much to do with Quorum or the team that we were working on. I probably could've bumped into him in the accounting department and we still would've wanted to work together on solving different types of problems. Patrick Nielsen: 44:59 It probably wouldn't be in the accounting department, but yeah. Working at a large corporation can be fun. But at least for me- Amber Baldet: 45:10 I didn't say it was fun. I just said it was exposure to a lot of— Patrick Nielsen: 45:11 I found it ... I did find it fun, but only after applying kind of a systems thinking hat to a large organizations. Like all the processes that Amber just described. If you are just kind of tired, if you tire easily of these kind of human processes and how much communication overhead there is in a large organization, then something as simple as saying, "Oh, we don't have a GitHub account, we need to open one." If you're just thinking technically, it's like just go do it. It's not that hard. You click a button, you type in an email and a name and then it's done. In a large organization- Amber Baldet: 45:46 Whose email? What's the recovery if that person leaves? What's our CLA for this project. Patrick Nielsen: 45:51 In a large corporation, that will take many months. And there are a lot of things that go on in those many months and there are a lot of problems and a lot of things that we have to do for many different reasons. And if you can be excited about understanding those dynamics, then it can be fun. But- Amber Baldet: 46:11 What's the reputational exposure of open-sourcing a project that then becomes unsupported? What happens if we get a pull request from a competitor? What happens if we get a pull request from another highly regulated entity like a central bank? There is a lot to think about. Not to go too far off topic, but there's a lot of other great organizations like FINOS that we also work with that help in the financial industry to help large entities think about open-source and how to do that. But I see them kind of running the race that I kind of had to do by myself early on in a lot of the open-sourcing work that now many banks, they're kind of like, there's this momentum building behind it. So, I think now is actually a really great time to go be working, especially in the larger financials on these kind of cool innovation programs, whether it's blockchain or, I don't know, cognitive or whatever the hotness is this week. Amber Baldet: 47:00 But there's so much funding because they all realize that they have to transform, the you can learn a lot there and then you can take that kind of learning and go out and start a tiny company where suddenly, yeah, it does suck to not be able to travel business class anymore. But you have the autonomy to not need to ask seven levels of operating committees like, "Can I buy this stapler?" So, there's value on both sides of the fence. Joe Petrowski: 47:23 Yeah. I've never worked in a financial company, but I agree with you from my history that a lot of startups are very optimistic, which is great, but then sometimes you're like, "Oh, we have this idea. Let's just try it and see if it works." And if you come from a bigger institution that maybe works in like mission critical systems, the attitude is very much like, "Okay, you have this idea. How could it possibly go wrong?" And it's a very healthy way to think, especially when we're talking about these systems that, like you said earlier, like the user is everybody. So, you have to think about like what happens if XYZ and have like a plan for this and prevent it if it's actually like a bad consequence. Amber Baldet: 48:00 Yeah. The mission critical thing, it's probably exactly what you were about to say, it's a good comparison to kind of having security people on your team early, or being security people, that that thinking of how could this go wrong as opposed to always imagining that the happy path is where you're going, that is probably the most important part of systems design in my opinion. Patrick Nielsen: 48:21 Yeah. And large organizations are filled with people who have concerns about things that might go wrong, especially if it's their area of concern or responsibility. Joe Petrowski: 48:31 Okay. Final question. Somewhat cultural. There's a lot of tribalism within the crypto community. Amber, you settled the #crypto debate with cryptoclidus. What animal will unite the crypto community? Amber Baldet: 48:44 What animal? Yeah, I mean, that's because #crypto, crypto means cryptoclidus, right? That was actually something my four-year-old-son pointed out in his dinosaur encyclopedia, although to be fair, he would point out if he were here that it is not a dinosaur, it is a marine reptile. So, what will unite us? Patrick Nielsen: 49:03 I'm going to go with otters. Amber Baldet: 49:04 Yeah. But otters is just the easy choice because otters are magic. Patrick Nielsen: 49:07 Right. QED. Amber Baldet: 49:10 QED. We're going with otters. Joe Petrowski: 49:12 Okay. Amber and Patrick, thank you so much for coming on. Patrick Nielsen: 49:14 Thank you. Amber Baldet: 49:15 Thank you. Joe Petrowski: 49:18 Thanks for listening to Relay Chain. I'd love to keep in touch. Follow us on Twitter at @relaychain or email podcast@parity.io. Our team at Parity includes some of the leading peer-to peer networking developers, consensus algorithm inventors, blockchain innovators, and Rust developers. If you want to learn more about our work or want to work with us, visit our website at Parity.io and sign up for our newsletter at parity.io/newsletter.