Episode Transcript
[00:00:09] Speaker A: Welcome to the rubric. I'm your host, Joe Andrew.
[00:00:12] Speaker B: I'm Erica Connell.
[00:00:13] Speaker C: And I'm Eric Schu.
[00:00:15] Speaker B: Today we'll talk with two of the authors and implementers of Did PKH, Wayne Chang and Joel Thorstenson.
This is part one of a two part interview with Wayne Chang and Joel Dorstensen about Diz PKH. A continuation of the conversation can be found in the next episode.
[00:00:36] Speaker D: So I call this the opera Winfrey method of distribution.
[00:00:42] Speaker A: On the rubric, we talk to the folks making decentralized identity happen. We chat about the technologies and motivations behind decentralized identifiers, including dids, did documents, and did methods, so that our listeners, that's you, can make better decisions about which did method is best for your use.
[00:01:00] Speaker B: Decentralized identifiers enable verifiable interactions without dependence on a trusted third party. So instead of being forced to use centralized verification services like Facebook, Google, or the Department of Motor Vehicles, dids can be created by anyone, anywhere and be used for any purpose.
[00:01:19] Speaker C: Did methods are the magic ingredient that give dids their flexibility. Before creating any specific did you first choose a did method, which determines how you perform the create, read, update, and deactivate operations on a did of that method. Once created, each did includes the name of its method in the identifier itself. This is so when you use the did. Others know how to retrieve the associated did document that contains the cryptographic material for verifiable interactions.
[00:01:46] Speaker B: Different did methods use different underlying mechanisms with different performance, security, and privacy tradeoffs.
[00:01:54] Speaker A: This show the rubric reviews different did methods with their creators and implementers so you can make better decisions about when and how to use dids in your applications.
[00:02:05] Speaker B: Joel Thorstenson is co founder of three Box Labs and co creator of Ceramic Network. He's been working on user centric identity and data since he first joined consensus in 2015. Before diving into crypto full time, Joel studied complex adaptive systems in Sweden. Joel, welcome to the show.
[00:02:25] Speaker E: Yeah, thanks for having me.
[00:02:26] Speaker C: Wayne Chang is the co founder and CEO of Spruce Systems Incorporated, a digital identity startup that focuses on open source and user control of data. He is an active contributor to the self sovereign identity ecosystem and was a former co chair of the W three C verifiable credentials working group. Prior to founding Spruce, he worked on decentralized identity at consensus and built an acquired health tech startup. Wayne, welcome to the show.
[00:02:52] Speaker D: Thanks. Really great to be here.
[00:02:55] Speaker A: Great, let's get started.
Did PKH is the minimalist multi blockchain did method designed to work with any blockchain with minimal fuss. In your words, what's did PKH?
[00:03:10] Speaker D: So I can start with this one. DidPKH stands for. Well, PKH stands for public key hash. And it's the recognition that a lot of these blockchain accounts are actually just hashes of public keys. So by being able to connect a lot of these to the, you know, I think it's one of the best potential distribution events ever. So I call this the opera Winfrey method of distribution. If you talk to a lot of people who have blockchain accounts, whether that's Ethereum accounts, whether that's cosmos accounts, solana, et cetera, or EVM compatible accounts, they already have key material, and they use the key material to derive the blockchain accounts by taking the public key hashing it, maybe performing additional transformations, like chopping off a few bytes. So basically, we wanted to say to all these people, well, if you already have a blockchain account, check under your seat, you have a dead right. And we think that there's just such an alignment between people working with blockchain accounts who want more digital sovereignty and control over their digital assets and also data and the goals of the decentralized identity community, which are pretty aligned. So by being able to connect these two different ecosystems, we hope for a lot more interoperability and giving the did ecosystem access to a lot of builders in the blockchain ecosystem who build tons of dapps. That, to me, is why did PKH came to fruition in the first place and a lot of the motivation behind it.
[00:04:41] Speaker C: So I think you already touched on this, but. So maybe I'll direct this question to Joel, but what problems were you interested in solving when conceptualizing did PKH? Everyone gets a did if you have a blockchain account. What are you hoping people do with this?
[00:04:59] Speaker E: Well, it's more like, what are we hoping?
Which users can we actually address? Right.
We've been building in the sort of crypto web three ecosystem for quite some time, and a lot of people already have wallets, but they don't natively interoperate with the did standards, which we use in our protocol.
And so by making all wallets dids, we sort of have this sort of way better way of interacting with the existing users that is already in the ecosystem.
[00:05:41] Speaker A: Okay, could you walk us through sort of the basic create, read, update, and deactivate operations? How do those work with did PKH?
[00:05:50] Speaker D: Yeah, so I will talk about create and read, update and delete are not supported. So for create, it is very much like did key. It is what I call a purely generative did method, in that by creating one of these identifiers, you already fully create what you need for the did method to resolve or read, depending on what you want that r to stand for. Call it resolve. To resolve the did method, you're able to take a lot of the part of the identifier that represents the blockchain account and that becomes part of the verification method for the did. So basically, if you're trying to sign something with like an Ethereum address, Ethereum uses sec p two, five, six, k one, the bitcoin curve under the hood. And for the Ethereum address to get there, you take the kitchen hash of the public key and you chop off 20 bytes, I believe, and then bam, you have an Ethereum address. Right? So that is also the verification method. When you sign something and you need to validate that it's been signed properly, then you check the signature as you would normally for that public key. But you add the extra step that you have to perform this transformation to get back to the Ethereum address to ascertain it was signed correctly. Right? So when you resolve to a did method, that's how we can just copy and paste the Ethereum address from the identifier as the verification method. And you need no further data stores or queries past that, very similar to did key, with a few extra steps to make it compatible. One of the nice things about this is that you can, upon a visual scan, just see the exact similarity between an Ethereum address and what shows up in the did.
And because this is all the data that you access, it's an identifier itself, purely generative, as it were, then there's no other data stores to fetch or update. So there is no update or delete.
[00:07:46] Speaker A: Okay, the update and delete makes sense. I'm trying to follow with the Ethereum address, which you mentioned is it's a public key and you drop off a bunch of bits. How do you get those bits back? Because I understand the did PKH would expose the Ethereum address, but then how would I get the public key from that?
[00:08:04] Speaker D: Yeah, well, so this really depends on which blockchain you're using. So for the bitcoin curve in particular, when you're using ECDSA for signatures, there is something called EC recover that you can use to recover the public key from any kind of signing. And that's supported by bitcoin curve. If we use Edwards curve like Solana does, I believe this is no longer possible or convenient. So you may need some out of band way to know how to verify things, and this is a challenge for some things.
[00:08:37] Speaker A: Okay, so specifically for the did ether, there needs to be some additional information above and beyond the did in order to get to that public key.
[00:08:45] Speaker D: Yes, and it wouldn't be did ether, it would be did PKH specialized into basically the Ethereum improvement proposal that describes facts about an Ethereum address. That's the level that we standardize on.
[00:09:00] Speaker A: Yeah, that's a good correction. I appreciate that.
[00:09:04] Speaker B: All right, how much influence did key provide when you were coming up with did PKH?
[00:09:12] Speaker D: I think that this purely generative aspect of it is part of the influence, although there are other methods like it. I think that did key is base encoded a certain way and so are blockchain addresses. So we don't use multibase for the did PKH because we care a lot about structural similarity. Like when you look at the did PKH version, you look at the Ethereum address, we look at the didph version, you look at the bitcoin address that it is basically the same thing. So upon a visual scan you can easily determine if that's correct or not without mangling into a different format. So that's really a big deviation from it. I think otherwise conceptually it's very similar.
[00:09:56] Speaker E: I think another thing that's worth mentioning probably is that you can specify also which blockchain your account refers is on. So for example, the Ethereum blockchain, there's like a bunch of different EVM compatible blockchains that have the same format for their addresses. So how do you know which EVM chain you're resolving this account for? So to solve this problem, we're actually not only using sort of like the blockchain address, we have like a chain identifier, so that identifies like a namespace for the blockchain, which in the case of Ethereum is EIP one five five. And then there's a colon, then there's a number that identifies the sort of specific chain id of an ethereum like blockchain. And similarly for bitcoin, we also have this sort of like chain identifier. So that can represent bitcoin accounts, it can represent dogecoin accounts and so on.
[00:10:56] Speaker D: And I think I'll also add that the use of basically public key material or things derived from public key material as an identifier does predate dids as a concept. And this goes as far as back as bitcoin in 2009 when basically the bitcoin addresses were discussed. So I think that it's interesting that you can just start adding these things and they're dids, because I think ideology behind them is the same, being able to self attest control over a certain identifier without further sources of evidence.
[00:11:30] Speaker C: So in the identifier itself, as an example, just to make sure I'm understanding this properly, you'd have did Colon, pkh, just say eth for ethereum, and then another colon and a chain specific identifier before you get to the public key hash that actually represents the account.
[00:11:50] Speaker D: Yes, those were early discussions. Yes, go ahead, Joel.
[00:11:53] Speaker E: Yeah, true. I guess we can talk about the early versions of this right now.
The ethereum specific version of a PTH is did PTh eIP one five five, which is like the namespace of an EVM blockchain. If you're on Ethereum Mainet, then you have colon one. Which one represents Ethereum mainet, then colon, and then your Ethereum address.
So this method of representing a did is something called a Shane agnostic account id, which is something that we sort of adopted with the PKH standard because it already was a way to represent a wide array of different blockchain accounts.
Before we were using kipes, we had sort of like a more simplistic approach. And I'll let Wayne talk to that a little bit.
[00:12:53] Speaker D: Yeah. So I think that one of the important changes as we were moving to the broader community for this, there's a organization called the Chain Agnostic Standards association, or CASA, and they make these chain agnostic interoperability proposals that's supposed to work across different kinds of blockchains, whether using different curves or different things to represent blockchain accounts. We wanted to leverage the fact that the chain Agnostic Standards association was already coming up with identifiers that could refer to a blockchain account on any blockchain, whether that's Ethereum, cosmos, et cetera. So being able to just rely on that body of work where there's already a community and discussion was really productive. And what we wanted to do for DIDPH, actually, what made this possible was that the standard that they were working on for blockchain account references, they weren't a valid Uri before, but I think there were some changes made to make it actually a valid Uri and therefore a valid suburi. So we could just put it after did PKH, a network selector, maybe a subnetwork selector, and then the actual identifier itself. So that was a lot of the motivation here. So people will actually register things like EIP one five five or whatever the representation is as the namespace within CASA. And from there there's a standard way that you would represent a blockchain account from that specific network, and that's the work that we lean on.
[00:14:27] Speaker A: So I want to talk a little bit about the target audience for using PKH you mentioned. In effect, it was designed to enable all these web three addresses, or blockchain based addresses, to sort of just bootstrap into the did world. Do you see did folks building out web three applications, or is it more coming from the other direction?
[00:14:48] Speaker D: I think it's more coming from the other direction. Just given the different network effects, I can't really tell you how many did uses there are outside of web three, depending on how you measure things. But for the web three ecosystem, I can tell you that it's really great to see an ecosystem of people who have adequate skill in key management, understanding of what it means to sign something. A lot of the times it's in the context of a financial transaction, but they kind of understand what it means to have the burden of being able to sign something with your key. And if you lost your key, there are some consequences, which I think is really hard to find in a user base and really necessary for a lot of the did use cases everyone's talking about. So we saw a lot of alignment in this demographic in terms of people who want to take more control digitally and also have are decently adept at key management, although it's always a challenge to get better at it. So I actually see the did ecosystem benefiting a lot from the millions or tens of millions of monthly active web three users who want to understand. Okay, great. We can do some financial transactions on the blockchain, but this is the greatest public key infrastructure event ever, and with motivated people who want to do more with their key material. So being able to connect it with the did ecosystem made a lot of sense from the other way around. Builders in the did ecosystem, looking at PKH and doing things there, I think it's a really curious suggestion, because I think that one of the benefits of the web three ecosystem is the builder community, and how developers help each other and have a lot of libraries to easily perform construction and get bootstrapped. There's a bunch of things like create, react, DAP, but just for web three and how you build one of these. So being able to have this market or community of developers, I think really short circuits the amount of time we need to build these decentralized web applications, whether it uses a blockchain or not so.
[00:16:52] Speaker C: There are three functions that are called out as specifically not supported by the did PKH specification. These are key rotation, deactivation, and key derivation related to the update and deactivate parts of crud.
Would you mind speaking to the consequences that arise from not having these functions?
[00:17:14] Speaker D: Yeah. Joel, do you want to take this one? I can. Happy to do it too.
[00:17:17] Speaker E: Yeah, I guess one thing to realize with the PKH is these accounts that become PKH dads, they already have this property of they're an identifier. They cannot change or rotate keys, and they are being actively used.
And so the consequences of that is sort of like already existing in the sort of different blockchain ecosystems. People are using these keys for both short term and also longer term sort of use cases. And yeah, sometimes people lose these keys. Sometimes people get things associated with them that they don't like.
That sort of has become sort of just like the background of what's going on in the public blockchain ecosystem.
And there's a lot of both pros and cons to this. And did peak age mainly inherits those property? It doesn't really change anything in terms of the consequences that were already there.
[00:18:33] Speaker D: I'll also add to this that basically the same properties for did key, right? Because you're literally just referring to a specific set of specific key pair. And I think that one of the implications here is, I think did methods won't have to all like, there are different tools for different jobs. And for example, a PGP key doesn't support key rotation by definition, right? So to expect it to do that, I think is unreasonable. I think that there are ways to rotate out your keys in GPG so that you can associate it to common identifiers. Right. And that's how we see a lot of the dids being composable eventually. So if we move to a world where you can basically use one did PKH as your authenticator right now, but you want to rotate it out for something else, you might need to upgrade to a more stable, more permanent identifier that you can basically use another did as part of the verification method. And should you decide to use a different key pair to be your authentication method, then you can just swap it out for a different did PKH. I think that a lot of it is thinking about how to build systems that work fine with did PKH, but as users have demand for more things like key rotation or ephemeral keys that are linked to a base identifier, that kind of thing, we're going to have to figure out how dids interoperate with one another to provide the full gamut of functionality for the use case.
[00:20:06] Speaker A: So you mentioned that you chose the cap ten standard or cape ten, actually. What is the preferred pronunciation within the web three community? I've always said cap, but do people say cape?
[00:20:19] Speaker D: I think it's cape, but I'm happy to accept either.
[00:20:22] Speaker E: There's a few different ones. I guess. Some people say cape, some people say CIP.
[00:20:29] Speaker A: All right, so you chose the Cape ten standard, which was developed by CaSA. Did you consider other standards? And why end up with cape ten? Like, what were some of the key features about it that won out the day?
[00:20:45] Speaker E: So I was actually part of also designing the cape ten standard and the reason we signed that in the first place, it was designed initially by the wallet connect team because they have this sort of protocol for connecting a wallet to a web three application, and they needed to support multiple blockchains.
And as they. And as I also started contributing, we looked around for solutions. There was something in w three c for linked blockchain account. I don't remember exactly what it was called, but it was like nowhere close to being something that was usable.
Nothing.
[00:21:27] Speaker D: You're referring to the blockchain account term definition within the security vocab. Right. And I think the extent of that definition said that. And this thing is a blockchain account. Right. And didn't provide any details around how you determine the network or what a valid format was. So to cross the t and dot the I there, we needed a bit more detail on how that stuff worked. And that's what the Cape ten gave us.
[00:21:54] Speaker A: I'm sorry, what did it give you?
[00:21:56] Speaker D: It gave you the ability to taper down specifically to which network could be represented and how. Because, for example, Ethereum mainnet has the chain id of one. And then I think polygon is like one, three, seven, and these are all EVM based blockchains. So to be able to demonstrate that, where do you stick the network id? And then bitcoin is different too. How do you determine the so called network id for bitcoin? Because dogecoin, for example, is kind of a fork of bitcoin before segue. We have to get into that. But basically thinking a lot about how you can have just one namespace represent a whole bunch of different accounts, because we really just care about how do you go from the key material to the blockchain account. Right. And if you want to further delineate to the network, you should be able to do that. But if you're doing the same transformation for EVM accounts, why define that as two separate things entirely?
[00:22:55] Speaker A: Okay, so cape ten depends on cape two, which is where the namespaces are defined.
How is that managed? Like, how do you register a namespace? What if someone else already grabbed your namespace?
How are the registry aspects of cape two? Could you talk us through how that works?
[00:23:23] Speaker E: There's a new process in the Casa organization, there's a repo called namespaces. And essentially in order to register a namespace, you make a pr, they're adding a new folder, it's the name of your namespace and basically an implementation detail of how you implement kype two, how you implement kype ten, and also like potentially other type references. So there's a few other ones.
One that might be relevant for this conversation is sign in with x, which is essentially a way of signing a message that can later be used as an object capability.
But anyway, so you basically make a pr to this repo, and essentially you have to show that hey, this is a real blockchain ecosystem that is being registered with this namespace and sort of make your case.
[00:24:22] Speaker B: Can you provide an example use case for why someone would want a did to represent a particular blockchain account?
[00:24:30] Speaker E: I mean, I guess I have a wallet on my computer or on my phone, and I want to interact in an app that uses dids.
Now instead of having to install a wallet that's specific to dids, I can just use my existing crypto wallet with this application.
So the PKH represents my account and I can use that as an identifier in whatever application.
[00:24:57] Speaker B: Right? So it could save a step or save.
[00:25:02] Speaker E: It'S basically like a coordination cost sort of thing.
We're building solutions.
Both Wayne and I are building tools that enables developers to build applications. And if we needed to build a wallet for the ids, then we have to build this entire other component. And what we realized is like this huge ecosystem of people who are already built a bunch of different wallets that handle cryptographic keys in a secure way, in a way where users are also aware of sort of key management in a sort of healthy way. And so why can't we just make these existing developers that are building these wallets, why can't we cooperate with them? And I think that's the big benefit we're not trying to, oh, we came up with a new did method, so we need to build a wallet for it. And then we have to spend a huge amount of effort.
[00:25:56] Speaker B: Right? Yeah, that makes sense. Saves time and is a little more efficient.
[00:26:02] Speaker D: Yeah, definitely. I would also add to the security of it too. A lot of these wallets have had billions of dollars of funds passed through them without issue, right? Some of them have had issues and had to iterate and remediate. But that just is the evolving state of key management. So to not have to solve that class of problems and to watch it be solved for millions of people already with stuff at stake, not just people using it lightly, but sending around nontrivial amounts of money, there is a lot at stake to keep it secure and being able to rely on that as a foundation instead of try to reinvent from scratch. We don't want to roll our own key management to the fullest extent possible so that we could build on that I think is really productive and secure and short circuits a lot of things without taking shortcuts.
[00:26:48] Speaker C: Is there off chain creation for did PKH dids? And is it chain dependent?
[00:26:54] Speaker D: If so, there's absolutely off chain creation for DPKH dids, because you just think of a random number that happens to be elliptic curve or whatever your scheme is, and you're able to create one without ever touching a blockchain, right, just like did key or any other generative did method, that's how you produce these things, whether you use it with a blockchain or not. Totally up to you.
[00:27:19] Speaker A: Okay, I'd like to shift the conversation a little bit to the people involved, starting with you two. How did you get involved with DidPKH?
[00:27:29] Speaker D: I can start. So basically, in our work with signing with Ethereum, we were thinking a lot about using passwordless login, using Ethereum accounts. So being able to use your Ethereum account to sign into a website instead of creating a transaction on the blockchain. Again, this is really thinking about the web three ecosystem where sign in with Ethereum would actually be the best way for them to log in because you wouldn't have to collect an additional email or anything like that, right? So basically this got us thinking about, okay, after you sign in, what else can you do if you're expecting that the user already has key pairs? And of course we drew a lot of parallels to the dead ecosystem. So how do we give Ethereum users and other blockchain users the full benefit of the did ecosystem? Things that are coming online, like these data vaults or identity hubs or whatever we're calling them, where people can manage their own data in the cloud somewhere or on their server, these all assumed using the did standard, right? So to be able to give Ethereum users the benefit of being able to access the dead ecosystem, and vice versa. The dead ecosystem could have a user base, which has been one of the, I think, most difficult things for the ecosystem to come to emergence. It seemed like a really good idea to figure out how to connect the two, right? So to be able to extend this functionality is the answer for us. And we're really happy to collaborate with folks like Joel and ceramic on figuring out more than just one company that want to use this, you know, really happy to co develop that. And I'll hand it to you, Joel, if you wanted to add more.
[00:29:10] Speaker E: Yeah, well, from our of. So we had a separate dad method that we were using for our protocol, but we also had some sort of way of interacting with users existing blockchain wallets already. And we had this sort of like, we're using type ten as a separate thing from the did to link a blockchain account to a different identifier to a different did.
But it felt like impure, like we were using a did for certain things. But then we're using this cap ten link, which was sort of like not really a did, but something different to link. And as we had sort of worked with that solution for a while, we started looking into different ways we could use more instead of generating this did the separate did that we were having. It's like using the type ten link more directly, and we're thinking a bunch about how to do that.
And then sort of like the collaboration with Bruce and Wayne came up and we sort of like, yes, this makes so much sense, let's just continue along this line. And then we also started to leverage the work that they've done on signing with Ethereum, just because it sort of allows us to create a much better user experience.
What you can do with this gives users just a way better flow through web three application.
[00:30:47] Speaker B: We'd like to learn a little bit about why do you do this work in SSI? What is important about it to you personally?
[00:30:55] Speaker D: So for me, a lot of it is about moving networks, the Internet and digital realms to how I think that people deserve to be treated there. I think that when I worked on a healthcare company, health tech company, I had my first run ins with these really horrible health tech integrations, being able to speak things like HL Seven, and a lot of the vendor lock in that came around those. And it wasn't necessarily anyone being nefarious, but it's just kind of the state of the technology in terms of being able to let patients have all their data in the same area, so that when they're going to the next appointment, it's there for them and they don't have to just pull it together across five different places. Some of them they don't even know about. Right? So this idea of digital user empowerment is really important to me, thinking about how do we basically help people in their digital world have the same kinds of guarantees that they have today in the physical world? You don't have to ask a tech company if you're going to present your passport or your driver's license, right? So why should you have to ask for that permission in the digital world as well? So being able to keep things, as we transition to the digital world without these sort of digital land grabs, where just because someone has all the engineers and they can implement the systems and store data cheaply or at scale, I don't think with the improvement of technology on the track that it is, I don't think there are many good arguments for the governance of these data to kind of be delegated to other places. So I care a lot about solving this principal agent problem where we see over and over again that people who trust people to act as their data stewards and seem to, even though these data stewards today may have competing interests, including making a business on selling products derived from data and saying, oh, don't worry, we'll never do that, and then repeatedly getting fined for doing exactly that. Right. So I think that there's a principal agent problem there, and we can move to decentralized protocols so that people can choose who can help represent them where their data is stored, and have more input into this process in a way that doesn't conflict with their interests, in a way that's incentive compatible. And I think that would be a much better way to go about digitally. So that's why a lot of this stuff matters to me. And a big part of that is finding out pragmatically, how do you get this adopted? What are user demographics, who are really open to this and are values aligned and want to experiment? So the web three ecosystem has actually been really huge for that, because I don't know where you find another developer ecosystem so excited about building new things, and users with those kinds of values, eager to experiment and gain technical knowledge so that they can continue doing that. That's a lot of why this work is meaningful for me, and I want to continue at it.
[00:33:58] Speaker E: Yeah, it's a really deep question.
Why do you think this matters, and what do you think what you're doing with this sort of technology matters for me, it goes back pretty far. So I was playing around a lot with open source technology earlier in life, and it sort of made a lot of sense, but a lot of the rest of society didn't make that much sense.
It was more nonsensical. And so when sort of, like this technology around cryptocurrencies and this blockchain technology started coming around, that was sort of a shift in my understanding of sort of what was possible and what we could create in terms of how we organize communities and societies, and generally humans on the planet.
And to do that, we need a lot more sort of infrastructure than only the ability to send bitcoins between two computers.
The way we organize is through communication and data. And currently, all of that is controlled by companies can't really trust and have proven themselves to be extremely untrustworthy. And so the only way we can get around that is actually building infrastructure where we can verify what is being stated, what's being said, and who actually claimed what, who actually sort of said what, or who invented or who came up with concepts so we can have attribution across time. And I think SSI and some of the technologies around it can really help solve some of those problems.
[00:35:59] Speaker D: Yeah, I think a big reason for a lot of the consolidation of data into a few entities these days has to do with the historic cost of scale in, let's call it the early days of cloud computing, where basically, if you're already running a few servers and you have engineers who are specialized at operations or DevOps, it's really cheap, comparatively, for you to just run more servers and host more data. So I think there was a significant cost advantage here that led to a lot of the consolidation of data, because, hey, it's easy for me to do and keep secure. Why not just hand it to me? And that's how we saw a lot of these. I think large silos just start to aggregate. But I think, again, because we're seeing the shifts in costs of computation, again, where it's feasible for everyone to run a server in the cloud management is a different story, I admit, but I'm optimistic that we're willing to pay a little bit more, because it's always, I think, more expensive and to coordinate and run a decentralized network as opposed to a monolithic one. But I think that trade off could be worth it if you look at it from other dimensions than just cost of computation. If you look at the social costs of not having your data in one place, but across many different data vaults that are rightfully owned. So I think that exploring these topics are very topical, especially given a lot of the scrutiny that we're starting to see for platforms. And I'm excited for what's next.
[00:37:30] Speaker B: Can you give us an example of how did PKH might help solve this principal agent problem?
[00:37:37] Speaker D: Yeah, so I think one of the really important points of moving people, empowering people with public key infrastructure, I think, is that you can make digital statements, you can sign for things just as you would sign for something in real life. And before that, you couldn't really do that. You had to just rely on someone to do that on your behalf. Right. And I think that's very empowering, because all of a sudden you can sign a bunch of things, including delegated access. You can sign a permission slip to access some aspect of your private data vault or something you have in public and make changes to it, and that can be recognized before public key infrastructure or having users have these private keys they can use, you would have to trust a steward to do that on your behalf. Right. So unlocking this direction of letting the end user decide, and especially one with an existing critical mass so we can actually start to see it play out in the market, that's exciting, and I think helps get us there.
[00:38:40] Speaker B: Yeah, it is exciting. Thank you for that example.
This is the end of part one and concludes our show today. The conversation continues in our next episode, and that will bring us to the end of our show today.
[00:38:56] Speaker A: Wayne, thank you for joining us on the show. Joel, thank you. Thanks also to our staff, our producer, Eric O'Connell. My co host, Eric Shu, and I'm your host, Joe Andrew.
[00:39:07] Speaker B: Wherever you find the rubric podcast, please take a moment to subscribe to our feed so you'll be notified when our next episode is released. We look forward to you joining us next time.
The information, opinions, and recommendations presented in this podcast are for general information only, and any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belong solely to the speakers and not necessarily to the speaker's employer, organization, committee, or other group or individual.
