Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.
In the current web model, users do not own their data or identity. They are given accounts by companies and their data is held captive in app silos. To create a new class of decentralized apps and protocols that put individuals at the center, we must empower them with self-owned identity and restore control over their data.
Components of Web 5
There are three main pillars of the decentralized web platform, all of which are based on open standards.
Decentralized Identifiers
The identifiers we know and use today are owned by the government, a company, an organization, or some other intermediary. For example, our email addresses and social media handles are identifiers associated with us but are owned and controlled by the service providers. These companies have the right to ban, disable, or delete these identifiers and we have little to no control over this.
So before we can realize truly decentralized applications, we need decentralized identifiers that users own and control. This removes the dependency on centralized entities to authenticate and represent us.
Decentralized Identifiers (DIDs) are a W3C standard. They have a standardized structure that essentially links to you and your information.
They are a long string of text that consists of three parts:
- the URI scheme identifier, which is did
- the identifier for a DID method
- the DID method-specific identifier
DIDs are the only component of Web5 that touch a blockchain, which is generally limited to anchoring the keys/endpoints linked to the ID.
That being said, anchoring DIDs on Bitcoin (or any blockchain) is not a requirement. In fact, what's great about having the standardized formatting for DIDs is that they can be anchored anywhere or not anchored at all and this still works, although with varying levels of decentralization.
Here are examples of DIDs on the Bitcoin blockchain, the Ethereum blockchain, and the web. Notice they all use the same format: scheme, DID method, and DID method-specific identifier.
did:btcr:xyv2-xzpq-q9wa-p7t
did:ens:some.eth
did:web:example.com
Because personal data is not stored on the blockchain, the DID essentially acts as a URI that associates the subject of the DID (the person, company, or object being identified) with a DID document that lives off-chain.
DID Documents are JSON files stored in decentralized storage systems such as IPFS, and describe how to interact with the DID subject. The DID Document contains things like the DID subject's public keys, authentication and verification methods, and service endpoints that reference the locations of the subject’s data.
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:ion:EiClkZMDxPKqC9c-umQfTkR8",
"verificationMethod": [
{
"id": "did:ion:EiClkZMDxPKqC9c-umQfTkR8",
"type": "Secp256k1VerificationKey2018",
"controller": "did:ion:EiClkZMDxPKqC9c-umQfTkR8"
}
],
"authentication": ["did:ion:EiClkZMDxPKqC9c-umQfTkR8"]
}
Verifiable Credentials
Verifiable Credentials are a fully ratified W3C standard that work hand in hand with Decentralized Identifiers to enable trustless interactions - meaning two parties do not need to trust one another to engage, but claims made about a DID subject can be verified.
For example, Alice needs to prove she has a bank account at Acme Bank. Acme Bank issues a cryptographically signed Verifiable Credential which would be stored in Alice's identity wallet.
The credential contains the issuer as Acme and the subject as Alice, as well as the claims, which are Alice's account number and full name.
Upon request for proof of banking, Alice presents the Verifiable Credential that's cryptographically signed by both Alice as well as her bank.
This is an easy, machine-readable way to share credentials across the web. The Verifier does not know or trust Alice, but they do consider Acme trustworthy, and they have essentially vouched for Alice therefore distributing trust.
Decentralized Web Nodes
Today, centralized entities act as our data stores. Applications hold all of our content and preferences on their servers.
Decentralized Web Nodes (DWNs) change this by allowing us to decouple our data from the applications that we use, and instead host our data ourselves in our own personal data stores.
BlueSky is a good example; it's a decentralized social media app. With BlueSky, your tweets and your connections aren't stored with the application. They are stored with you. So you can present your content on any decentralized social media app you want, not just BlueSky.
Your DWNs can hold both public and encrypted data. For example, in the case of a decentralized social media app, you'd want data like your posts and your connections to be public but things like your DMs to be private.
Your decentralized web nodes do not live on the blockchain. You can host your web nodes anywhere (your phone, computer, etc) and can replicate them across your devices and clouds and all data will be synced.
While self-hosting your DWNs provides a means for decentralizing your data, we recognize some users will be more comfortable with others hosting their web nodes for convenience sake. We envision there will be vendors offering to host your web nodes for you. The good part about that is you can encrypt any private data so unlike today where cloud hosts can scan everything that you host there, you can still maintain some privacy even if you have your web nodes hosted by intermediaries.
Your DWNs are associated with your Decentralized Identifiers and are listed in a DID document.
Notice the serviceEndpoint section of the DID doc specifies service endpoints and provides URIs to the decentralized web nodes.
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:web:example.com:u:alice",
"service": [
{
"id": "#dwn",
"type": "DecentralizedWebNode",
"serviceEndpoint": {
"nodes": ["https://dwn.example.com", "00:11:22:33:FF:EE"]
}
}
],
"verificationMethod": [
{
"id": "did:web:example.com:u:alice",
"type": "Secp256k1VerificationKey2018",
"controller": "did:web:example.com:u:alice"
}
],
"authentication": ["did:web:example.com:u:alice"]
}
Given an application has the address to your DWN, they can send you a request for data.
This represents a request from an application to obtain all objects within a DWN that follow the SocialMediaPosting schema:
POST https://dwn.example.com/
BODY {
"requestId": "c5784162-84af-4aab-aff5-f1f8438dfc3d",
"target": "did:example:123",
"messages": [
{
"descriptor": {
"method": "CollectionsQuery",
"schema": "https://schema.org/SocialMediaPosting"
}
},
{...}
]
}
The data within DWNs are JSON objects that follow a universal standard, thus making it possible for any application to discover and process the data given its semantic type.
If this data is public, those objects will be automatically returned to the application, and if the data is private, the node owner would need to grant the application access to that data.
Identity Wallets
Obviously all of this is pretty complicated, especially for non-technical users. So we need a simplistic, easy to use interface that will allow people to access and manage their identity.
A well designed identity wallet would provide ways to manage the data stored in decentralized web nodes, the decentralized IDs and the context in which they should be used, verifiable credentials, and authorizations.
Decentralized Web Apps
Web 5 enables developers to build decentralized web applications (DWAs) on top of it and it’s all open source! You're free to use it as your foundation and focus your attention on what you really care about, your app. Web5 brings to DWAs what cloud and application servers bring to enterprise apps. It does the hard part. It brings decentralization. By building your apps on top of Web 5, you get decentralization and identity and data management as part of the platform.
This is definitely a fundamental change in how we exchange data, but it's not a total overhaul of the web we already know. This works like Progressive Web Apps, but you'd add the decentralized web node SDK and then applications are free to really go serverless because the data isn't stored with them.
The sky's the limit to what you can build on top of this platform, but here are some cool basic examples.
Music Applications
No one likes recreating their music playlists over and over again for different apps. With Web 5, you wouldn't have to do that.
In this example, Groove has access to write to Alice's decentralized web node and adds a new entry.
Tidal has access to read from Alice's DWN, so can read the new entry that was added by Groove, and now Alice has her playlist readily available on both apps.
With the continuous utilization of the data across apps, not only do Groove and Tidal get access to Alice's data, but they use it to improve her user experience, thus creating a stronger experience than Alice could have ever gotten had she not used this tech.
Travel Applications
Your travel preferences, tickets, and reservations are scattered across so many different hotels, airlines, rental car agencies and travel apps, making it really difficult to coordinate. Heaven forbid there's any hiccup in the system such as a delayed flight. You end up trying to get in touch with the car rental place to let them know you'll be late for your reservation, and if it's really late, you'd want to call the hotel to ask them not to give away your room. All while you're hustling and bustling at the airport.
Web 5 can help unify these various app experiences.
If Alice gives the hotel, the airline, and the rental car agency access to the Reservation and Trip objects in her DWN, they can react and adjust accordingly to any changes made.
These are just a few applications that can be realized by building on top of Web 5. There's so many more possibilities once the web is truly decentralized the way it was always intended to be.
Top comments (0)