.. and press ENTER to ask a question on web5, how to write code and more.

Skip to main content

What is Web5?

· 12 min read
Angie Jones

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.

The pillars of Web5 are Decentralized Identifiers (self-owned identifiers that enable decentralized identity authentication and routing), Verifiable Credentials (data formats and models for cryptographic presentation and verification of claims), and Decentralized Web Nodes (data storage and message relay nodes that serve as the foundation for decentralized apps and protocols).

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.

A DID is comprised of three parts: Scheme, DID Method, and DID Method Specific String

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

Storing DIDs on ION (a Layer 2 DID network that runs on top of Bitcoin) is a preferred design decision for the implementation of Web 5. ION is a decentralized replacement for DNS for identity identifiers, so there are no authorities, coordinators, tokens, or other centralized bottleneck.

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.

Illustration of Acme Bank issuing a verifiable credential to Alice’s wallet, and the wallet presenting the credential as proof of a bank account to a PFI Verifier.

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 version of Twitter that's in the works. 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 version of Twitter, you'd want data like your tweets 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.

Decentralized Web Nodes is an emerging standard for data storage and relay that enables entities of any type (people, organizations, etc) to send and store encrypted or public messages and data, enabling a wide variety of decentralized apps and protocols to be built on top. Features of Decentralized Web Nodes include: universally addressable, replicated, secure, semantic discovery, async message threads, supports any identity type.

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.

Identity wallets are mobile apps that provide UI and functionality to manage credentials and app data stored in Decentralized Web Nodes; sign, verify, discover, and present credentials to verifying parties; perform authentication and manage authorizations; support create, update, and recovery of DIDs across all supported DID Methods; maintain and enforce which DIDs are used with different people, apps, and services.

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.

Illustration of PWAs compared to DWAs. PWAs comprise of a web app that uses a service worker to pull from local cache and a centralized app server; whereas DWAs comprise of a DWN SDK and a service worker that pull from local cache and Decentralized Web Nodes.

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.

Illustration of Groove writing a new schema.org/MusicPlaylist object to Alice’s remote DWN and Tidal, who has read ability, reading the MusicPlaylist entry that Groove added.

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.

Illustration: Alice grants her hotel, airline, and rental car provider the ability to add schema.org/Reservation objects to her collection of trip-related data and also grants any app she chooses access to reservations and tickets stored in her schema.org/Trip data to help her visualize her itinerary.

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.

How to Get Involved​

While we’re super excited about this technology, there's still lots of problems to be solved. We welcome you to join us in making the web we all deserve.

  • Check out our GitHub projects, if you’d like to see more or contribute to the components.

  • We have open job reqs if you’re interested in formally working on decentralized technologies.

  • If you're a company who is trying to solve these same challenges or could make use of any of these components, we'd love to collaborate.

  • If you’d like to join the community, we’re on Discord.