 to meet Alice. Alice is tech savvy and what the kids call extremely online. Alice has accounts on just about every platform you can think of from social media to streaming services and she utilizes her trusty email address as a universal identifier. Unfortunately, one day Alice loses access to her email. Oh no, right? All of her two-factor authentications and app verifications are tied to that email address. So now, every app and service that collectively form her online identity is now suddenly out of reach. Her photos are trapped in one application, her playlists in another, her personal notes in yet another, and despite being the rightful owner, Alice cannot retrieve her content without access to that email. This unfortunate incident is a wake-up call, not just for Alice but for all of us. It highlights the vulnerability of the current web and our inability to own our identity and control our data. But wasn't the web meant to be decentralized? Indeed, it was from the very beginning actually. However, it's missing a key element that enables it, an identity layer. So applications that require user accounts have to collect our information in order to persist it with our content. And this model has made it very difficult for us to have agency over our information, if not impossible. What if we could own our identity and our data across the web? This is possible with Web 5. So Web 5 embraces the convenience of the account model of Web 2, but it restores control back to the users and ethos of Web 3. The combination of these two views is what we're calling Web 5. And this platform enables developers to build decentralized applications while abstracting away the complexity of doing so. So Web 5 is comprised of three core pillars, all of which are based on open web standards. We have decentralized identifiers, also known as DIDs or DIDs, verifiable credentials, and decentralized web nodes. And I'll go through each one of these in more detail. So the identifiers that we know and use today are controlled by some intermediary, whether that be the government or a company or an organization. For example, my email address is an identifier that's associated with me. Much like Alice, I use my email address across the web to authenticate and identify myself, but I don't own that email address. My provider does. My Twitter handle, also an identifier that's associated with me. I've built a following and created a brand around this lovely handle right there. But what we've seen, even very recently, with the rebrand of Twitter, did y'all see the stories where some of the handles were basically repossessed? Someone had the cool handle X. How cool is that? Snatched right from them. Someone had ad music. 16 years, they built a brand around that handle and overnight it was taken from them because it was never theirs to begin with. So before we can realize, truly decentralized applications, we first need decentralized identifiers that we own and control. Now, decentralized identifiers are a W3C standard. And they're basically this long string of text that's comprised of three parts. The first part is the scheme that's always going to be DID. It's letting us know this is a decentralized identifier. The next part is a dead method. So dead methods, there's various of these dead methods, and they basically describe how an identifier will be created, resolved, and managed. So you pick an identifier that gives you what you need, a dead method that gives you what you need, and then the last part of that string is the identifier itself that represents a dead subject. By dead subject, I mean the person, the place, or the thing that is being identified. So it's not limited to just people. Decentralized identifiers are the only parts of Web 5 that optionally touch a blockchain, and it's just the string. So because they have this standardized format, it can be used on any blockchain or no blockchain at all. For example, this first one is an identifier that is anchored on the Bitcoin blockchain. The second one is anchored on Ethereum, and the last one doesn't use blockchain. He uses the Web. Now, because that string is anchored somewhere, and it's standing by itself, it works as a URI that points to more information about the dead subject. That information is stored in what's called a DID document. And that document lives in some decentralized storage system, such as IPFS. The document itself is a JSON file, and it describes how to engage with the dead subject. So it'll contain the dead subject's identifier, the dead itself, of course, and then it'll also contain the public keys as well as authentication and verification methods. So that's decentralized identifiers. The next pillar of Web 5 is verifiable credentials. Verifiable credentials are also a W3C standard, and they work hand in hand with decentralized identifiers to enable trustless interactions, meaning two parties don't need to know or trust one another in order to engage. I have an example. Let's say Alice is applying for a loan, but the lender needs to verify a proof of income. Y'all with me? All right. So Alice's employer, Acme, will issue a verifiable credential to Alice, which she then keeps with her. She can store this in something like a digital wallet, for example. Let's double click inside of that credential to see what's there. So we have the issuer, who is Acme, and then we have the subject, who is Alice. More specifically, we have their decentralized identifiers here, right? And then we have claims that the issuer is making about the subject. So Acme is saying, hey, the person who has the decentralized identifier did example Alice. Her real name is Alice Smith, and her salary is $120,000. And then Acme has cryptographically signed this verifiable credential. So Alice keeps that in her little digital wallet. And then when the lender asks her for proof of income, she can present this verifiable credential to them. She cryptographically signs it as well. And now the lender can continue on with the loan application. Now, remember, this lender doesn't know or trust Alice, doesn't have to. It considers Acme a trustworthy entity. They know that it's Acme that the decentralized identifier was there, cryptographically signed. Therefore, Acme has extended trust to Alice. The last pillar of Web 5 is decentralized web nodes. So today, centralized entities act as our data stores. All of our content, our preferences, are stored in these apps, servers. The centralized web nodes changes this by enabling us to decouple our data from the applications that we use, and instead host our data with us. And we can reuse that data across the web in various applications. Blue Sky is a good example of this. Anybody on Blue Sky? Somebody got really excited about that. Okay. So Blue Sky for all intents and purposes is a decentralized version of Twitter, right? But instead of things like your connections and your tweets being stored with the app, it's stored with you in your own personal data store. What this means is if decentralized Instagram or decentralized TikTok pop up, I can take my connections. I can take my data in all of this and go to those apps with it intact. I don't have to start from zero because the data is stored with me. Okay. Now, decentralized web nodes is capable of hosting both public data as well as private data. So in the case of something like a Blue Sky, you will want stuff like your connections and your tweets to be public, meaning any application can query and read this data. And then things like your DMs, right? You want to be private, yes? So that'll be private and encrypted, and only applications that you explicitly give permission to can read that information. Now, the web nodes are also not hosted on a blockchain. They're hosted with you on your local device. It could be on your phone. You could have another one on your laptop. You could have some in the cloud. And what's beautiful is all of the data across them will be synced automatically. While this does offer a paradigm shift in the way that we exchange information, it's not a total overhaul of the web that we already know. Works kind of like a progressive web app where if you had a decentralized web app, you would add a Web 5 SDK in the flow, and then the app is free to truly go serverless because it doesn't have to host that data itself, right to the user's node. Now, remember the did document I told you about earlier, right? And we said that did document has things like the public keys and the authentication and verification methods. It also has another section in there for service endpoints, meaning how do I communicate with this did subject? Where does their data live, right? And in that part of the did document would be you arise to a did subject, the centralized web nodes. So given an application has my did, I authenticated with my did. It's able to resolve that did, see the did document, it sees where my web nodes are. It can send HTTP requests to those web nodes for information. This snippet is a query that is asking for all of the objects in the web node that follow a social media posting schema, right? So the data that's in the web node follows some semantic type, and that's what makes it interoperable across applications. So any of my data that was public that followed that schema would be automatically returned, and then if it was private, they would, I would have to give access to that app. Now, of course, all of this is pretty complicated, especially for non-technical users. So as I often remind builders in the space, the centralization is not a feature that your users are requesting, right? It should be an implementation detail. And so we are also building identity wallet that will allow users to manage this in a really, you know, user friendly way where they can manage multiple identifiers, right? I don't want just one. I want an identifier for maybe my personal life, one for my work life and have different web nodes associated with those. So I need to be able to manage all of that, my verifiable credentials, and things like that. So Web 5 enables developers to build decentralized web apps. And it sits on top of this Web 5 stack. These three yellow things, again, are open web standards, meaning they don't belong to any one company. What my team at TBD has done is implemented each one of these standards, aggregated them together to make this web platform. Given this, it's all open source, you're free to use it, but you don't have to worry about the implementation details of making your app decentralized. That's taken care of. You can focus your attention on what you truly care about, which is your app, right? So the sky is the limit in what you can build. I do have a couple of examples just to give you some ideas of what's possible. So let's say that Alice uses Spotify and she wants to try out Tidal because she heard, you know, they pay their artists more on the streams. But the thought of, like, recreating her playlist and stuff like that all over again, it's just too much. Enough to make her not give it a try. With Web 5, how this will work is instead of Spotify writing her playlist to their app service, they would write that to her decentralized web node, right? Let's say she's given Spotify write access to do that. Then when she wants to try out Tidal, she gives them read access and they can read all of those music playlist objects that have been written to her web node, no matter which app it came from and they are able to play her stuff. This resonated with me just last week when I got an email from Google saying that Google podcast was going to be discontinued. Y'all got that email? Well, that's my jam. I use Google podcast. And so I just started thinking, my goodness, I have, I'm subscribed to dozens of podcasts. I've listened to hundreds of episodes. Some I've started and not finished, but I promise I'm going to go back and finish them all. You know, I have a queue of episodes in the order that I want to hear them whenever I feel like listening to podcasts. If they shut that down, I'm going to lose all the fact. I want to take that with me. That's mine. That's my stuff. I want to take that to whatever new podcast service I go to and be able to pick up right where I left off. Medical records. It's another one that's dear to me. I have moved states three times in the last five years, which means every time I move, I have to get a new set of doctors. So here, you see Alice, she has a primary care physician. She has a gynecologist. She has a dentist. Now when she moves, you don't want to call these doctors' offices and plead with them to fax the information over to this other one and pray that they actually do it. Sometimes they do. Sometimes they don't. But I just don't want to manage all of that, right? With this, she's given each of her doctors reading right access to the patient records in her decentralized Web Note so they can write those records there. Now remember, they're all using decentralized identifiers, so any of these doctors can see who has written that record and be able to verify that, yes, that is a reputable source. That's a real doctor, not just Angie playing around in her Web Note. All right? So I want to show you Web 5.js, which is a library that we've developed. It isn't tech preview. Say with me tech preview. Yes, that means that we're not done. This is pre-alpha, okay? So don't build your production apps, put them in an app store and then call me when it breaks, right? This is a preview. You can play around with it and kind of get some ideas. And I want to show you what you can do with this. So because it's a JavaScript library, NPM install works just fine, so I've already done that part. And then I'm just going to import Web 5 from Web 5 API, yes. Okay? Given that when I'm ready to connect, so a user has come to my application, what I'm going to do is call Web 5.connect. And this connect function is going to look on the user's device to determine do they already have a decentralized Web Note that's local to this device and a decentralized identifier. If so, it'll just automatically connect to that. If not, it'll create the decentralized Web Note as well as the identifier for them. Okay? And what this is going to return is, let's say const, it's going to return us an instance of Web 5 so that we can do further actions. And it's also going to return us the decentralized identifier for this user, either the one they already had or the one that it just created for them. Okay? So now we have a little identifier. We know who we're working with. And that's it. No username, no password, anything like that. Now let's say we want to start writing to this user's decentralized Web Note. So the objects in there are called records, so we can say create a record. And we'll say const record equals await. And we're going to use that Web 5 instance. From there, notice here, I have an agent that's kind of like the wallet, right? I have a did. And these are like properties, right? So I have the did thing, so then I can start doing things with the did, like resolving it. Maybe I want to resolve that did so I can get their did document and determine what their authentication, verification methods, and I can make sure this is who they say they are. Or I can resolve that did and get the did document and get the Web Note, the remote ones, as well as the local one and stuff like that. And then there's DWN, that's for the Web Notes in BC for the verifiable credentials. So we're going to say DWN records.create. And when I create a record, I need to pass in two things. One is the actual payload. So that's from data. From here, I can write text records. We'll say, hey Octane, right? I can do images, JSON, blob streams, files, all of that. And then the other property here is a message. So this is where I put metadata about that payload. So I can do stuff like maybe say the data format is plain text. I can say the schema, for example, remember I told you about the interoperability between applications. So if this is following a certain schema, I would want to put that there. Let's just say schema.org slash text or something. I don't know if that's a real thing, but you can put that so that if another application wanted to query for records that match that schema, you have that there. I can put by default, the data that is written to the Web Note is private. So if I wanted this to be a public record, I would publish it. So I can say publish equals true. And that makes that data publicly available. And then this is writing to this user's Web Note. But let's say this is an application that's facilitating communication between multiple people. Maybe DMs or a chat app or something like that. I can write to somebody else's Web Note on their behalf. So I would say recipient and then put another did here. Maybe Bob's did. Okay. There's multiple things you can do there, but that will create a record. It will write that to the decentralized Web Note. All right. And then let's say I want a query for some records. To do that, I would say const records, wait, and then I'm going to use Web 5 DWN again and we'll say records.query. And from here I can specify what sort of message I want. And I can give it a filter. So I can say something like give me all of the records that match that schema, right? This one. And that'll give me this record as well as any other records that match that schema. Or I can say give me records that match a certain data format. So maybe I want all images if I'm a gallery app or something like that. Okay. And that'll give you an array of records back. And then I can update. Let's say read. We're going to read a record. So if I wanted the data, let's say text, I could say that record that I got. Record.data. And then I can specify the type of data I'm trying to read from that record. So is this a blob? Is it JSON? Is it stream? Is it text? And I can get that information. And then I can also, what else, update. So let's say wait.record.update. And then I would just specify, you know, whatever it is I'm trying to update. Hey, again, octane. And I need a little weight right here. Okay. And then last thing is delete. How would I delete based on this? Any devs in the room? Come on, y'all already know how to use Web 5. Await record.delete. Easy peasy. That's right. So this is Web 5 in action. As you can see, we've kind of abstracted away a lot of those details. It's not hard to use. You don't have to think about cryptographic keys and like how to do all of this stuff. All that is done in the background. When I've written and updated and deleted these records, it'll happen on their local web node, but then sync is done in the background on an interval. So it'll resolve their did. Look at all of their remote web nodes and make sure that all of that stuff is synced up together on a schedule. Okay. So that is Web 5 in a nutshell. Like I said, it's all open source, so you're welcome to use it. Don't publish your web app just yet until I tell you that it's ready to go. It's production ready. But you can play around with it. You can also contribute to it and help us make the web that we all deserve one where we own our identity and control our data. Thank you so much.