Reviving the Web: The Web's Identity Crisis, Web 5.0's Phoenix Effect, and the Decentralized App Renaissance

The internet has evolved through distinct phases in the vast expanse of the digital world, each shaping our online experiences. The current web model, Web 2.0, while offering a plethora of services and platforms, has inadvertently surrendered user sovereignty to centralized entities. This paradigm shift led to a growing identity crisis, where individuals have become data points in a vast, profit-driven ecosystem.

Amidst this crisis, the concept of self-sovereign identity (SSI) emerged as a beacon of hope, empowering individuals to reclaim control over their digital identities. However, the realization of a truly decentralized web remained elusive. Enter Web 3.0, a promising vision of a decentralized internet. Despite its potential, Web 3.0 has yet to deliver on its decentralization promises fully.

From the ashes of these unfulfilled aspirations arises Web 5.0, a revolutionary paradigm that heralds the revival of the web. It stands as a testament to the resilience and adaptability of the digital landscape, resurrecting the core principles of user empowerment and self-sovereignty.

PREREQUISITE

To fully understand the web and its struggle over the years, I will strongly recommend reading the first episode.

Below is a link to the first episode.

From Static to Smart: The Evolutionary Leap to Web 5.0

THE WEB'S IDENTITY CRISIS

Welcome to the digital maze where your online presence isn't quite your own! Have you ever clicked 'agree' to those app terms without a second thought? Web 2.0 ushered in a realm where companies behind your favourite apps possess considerable control over your data.

Let's journey through two vivid scenarios shedding light on this digital reality, unveiling how your online footprint dances at the mercy of these app architects.

Meet Shahinaz 👩‍💻 (a fictional character).

Shahinaz is a tech-savvy lady (extremely online) who manages her digital presence across diverse platforms, encompassing social media to streaming services.

She entrusts her entire online identity to a singular indispensable platform, let's call it "DigitalHub".

However, one fateful day, Shahinaz lost access to her DigitalHub account. Suddenly, her entire online world, comprising apps, subscriptions, and online profiles, becomes inaccessible. Her treasured photos are scattered across one app, playlists in another, and personal notes in another distinct service.

Despite being the rightful owner, Shahinaz faces the daunting reality of needing help retrieving her digital assets due to losing access to this crucial DigitalHub platform.

This unfortunate incident is a critical reminder, impacting not only Shahinaz but all of us. It highlights our current system's vulnerabilities, emphasising our limited control over our identities and shared data.

Next is a recent occurrence earlier this year, 2023. It was a recent happening with the MyChart app, a patient portal. MyChart app posted people's private health information on Facebook. Shocking right?

Whether deliberate or inadvertent, this has yet to be discovered. But this scary and shocking experience only shows a breach of privacy. An identity crisis where the patients involved question whether or not their data is theirs or the company's.

Picture this: the internet was supposed to be decentralized, right? That was the grand plan from the very beginning. However, it needs a key element that enables it—the IDENTITY LAYER.

Now, imagine a digital realm where owning our identity and data is the norm. Sounds too good to be true?

Welcome to the potential reality of Web 5, where taking control of our online existence might be within reach.

WEB 5.0: EMPOWERING SELF-SOVEREIGN IDENTITY (SSI)

Web 5.0 is a decentralized platform, unveiling a new identity layer for the web, enabling decentralized apps and protocols.

In the existing web framework, users are mere account holders, entrapped within app silos, devoid of data and identity ownership. To birth a new era of decentralized apps and protocols centred around individuals, empowerment through self-owned identity and data sovereignty becomes the clarion call.

Web 5.0 embraces the convenience of the account model of Web 2.0, but it restores control to the users by also embracing Web 3.0. The combination of these two we use is what Web 5.0 entails.

Image Credit: Mashable India

PILLARS OF WEB 5

• Decentralized Identifiers (DIDs) - Self-owned IDs

• Verifiable Credentials - Verification of claims

• Decentralized Web Nodes (DWN) - Personal Data Sores

Image Credit: tbd

1. DECENTRALIZED IDENTIFIERS (DIDs)

• They are self-owned identifiers that enable decentralized authentication.

• The identifiers we know and use today are controlled by intermediaries, whether the government, a company or an organization.

• Example: A user's email address is an identifier associated with them, with which they authenticate and identify themselves across platforms. But they do not own the email address; their provider does.

• Another example is a user's social media handle. It is also an identifier associated with them. However, they can wake up one day and have someone snatch that handle because they were not the owner of the centralized app in the first place; their provider does.

• Therefore, before we can realize a truly decentralized web, we all need decentralized identifiers that we own and control.

• DIDs are W3C standards. This implies that DIDs have been standardized by the World Wide Web Consortium (W3C). This international community develops open standards to ensure the long-term growth and interoperability of the web.

• This standardization holds significant implications for the future of DIDs and their potential to revolutionize how we manage digital identities.

• DIDs have a standardized structure that essentially links to users' information and are a long string of text comprised of three parts:information, and are basically a long string of text that consists of three parts:

Image Credit: tbd

1. SCHEME: The URI scheme identifier, as the name suggests, is an identifier of the scheme in question, which is 'DID'. This will always start a DID. The 'did' at the beginning of the illustration above states that it is a decentralized identifier.

2. DID METHOD: There are a plethora of these methods, and they describe how an identifier will be created, resolved and managed

3. DID METHOD SPECIFIC IDENTIFIER: This is the identifier and the DID subject. By DID subject, I mean the person, thing or place being identified. It's not just limited to people.

Storing Decentralized Identifiers (DIDs) on ION (a Layer 2 DID network on top of Bitcoin) is a prime architectural choice.

ION is a decentralized alternative to DNS for identity markers, eliminating the need for authorities, coordinators, tokens, or any centralized bottlenecks.

It is essential to note that DIDs are the only pillar or component of Web 5 that touches a blockchain.

With that in mind, anchoring DIDs to Bitcoin (or any blockchain) is not obligatory.

The brilliance of standardized DID formatting allows them to be anchored anywhere or left unanchored, and it still works, although with differing decentralization levels. Here are instances of DIDs on the Bitcoin blockchain, Ethereum blockchain, and the web.

Observe how they uniformly adopt the same structure: scheme, DID method, and method-specific identifier.

did:btcr:xyv2-xzpq-q9wa-p7t
did:ens:some.eth
did:web:example.com

Source: tbd

Since the string is anchored somewhere and it's all to itself, it acts as a URI that stores information about the subject. This information is stored in a DID document.

DID DOCUMENT

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.

Example: A DID

did:ens:some.eth

resolves to something like this

ipfs://...//shahinaz/did.json

Example of a DID Document:

{
  "@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"]
}

Source: tbd

An example generated for user Shahinaz

Source: Toyyib Muhammad-Jamiu

Another part of the DID Document is "Service Endpoint".

This states how the DID subject is communicated and the location of their data layer. This section contains the DID subject's Decentralized Web Nodes (DWN) URIs.

With this in place, data is owned and can be taken with the user as they traverse different decentralized apps.

So, a user's data on a decentralized Twitter platform is transferable to another decentralized Instagram without the need to start from zero building their profiles and connections.

This way, the web of our dreams gradually becomes a reality, and users have their handles, connections, and vital information intact and transferrable without breaking a sweat.

I can hear you say wow! Isn't that amazing?

The next pillar is Verifiable Credentials.

1. VERIFIABLE CREDENTIALS

• Tamper-evident credentials that cryptographically verify a claim.

• Also W3C Standard

• They work hand-in-hand with decentralized identifiers to enable "trustless" interactions.

• This means that two parties don't need to know or trust one another to engage, but claims made about a DID subject can be verified.

• Example: Shahinaz applies for an academic research grant with Sigma Xi, and the organization needs to verify her application involving her guarantor.

• So, her guarantor, NSE (Nigerian Society of Engineers), issues a VERIFIABLE CREDENTIAL to verify her claims as thus:

issuer: did:example:nse
subject: did:example:shahinaz
claims:
    name: Shahinaz Ahmad
    budget:$100,000
    guarantor's name: Nigerian Society of Engineers
    guarantor's worth: $50,000
+ Shahinaz's Cryptographical Signature
+ Guarantor's Cryptographical Sigature

This is an easy, machine-readable way to share credentials across the web. The Verifier does not know or trust Shahinaz, but they do consider NSE trustworthy, and they have essentially vouched for Shahinaz therefore distributing trust.

Here's a real-life scenario of how this process of verification is done, featuring a lady called Alice from TBD

Image Credit: tbd

So as discussed earlier, the DID is stored on ION (a Layer 2 DID network on top of Bitcoin). ION, being a decentralized alternative to DNS for identity markers, eliminates the need for authorities, coordinators, tokens and several hitches that centralization brings to the current web model.

1. DECENTRALIZED WEB NODES (DWNs)

• DWNs are personal data stores for public and encrypted data.

• All of our chats, preferences are in applications' servers for our current centralized web.

• DWN changes this by enabling users decouple their data from the apps they use and can reuse such data across other apps.

• Image Credit: tbd

• An example of a decentralized social media app is BlueSky, which utilizes DWNs against app servers.

• BlueSky is the decentralized version of Twitter.

• With BlueSky, your data is stored with you, unlike Twitter.

• With DWNs in place, users can take their data to another decentralized app.

• Imagine a user with 1 million followers who gets to engage in his business and posts on Twitter. This user will have to start from level 0 with 0 followers on another centralized application if he wishes to grow his business further.

• The thought alone makes it difficult for the user to go ahead and create a new account on this application; hence, growing his business on this platform becomes a dead idea or one that comes with a lot of perseverance.

• With DWNs on decentralized applications, this user can move his user base to another decentralized application without starting from the beginning. Growing his business on the new platform has become a reality.

• Decentralized web applications are not hosted on a blockchain.

• Web applications are hosted by users on their local devices.

• You can have it hosted on three (3) different platforms (phone, laptop, cloud) if you are using the three platforms.

• And the beauty of it is that all the data across them will be synced automatically.

• Looking at all the technicalities that these pillars entail, users might need help using them for decentralization.

• There is a need for a simple, easy-to-use interface that will allow users to use all these pillars and essentially make decentralization easier.

Worry less, as THE IDENTITY WALLET has got us covered.

THE IDENTITY WALLET

The identity wallet 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 authorization.

Below is an illustration on how user experience is prioritized with the identity wallet.

Image Credit: tbd

DECENTRALIZED WEB APPLICATIONS (DWA)

Web 5 empowers developers to create decentralized web applications (DWAs) atop its open-source architecture. It serves as your reliable base, allowing you to concentrate on what truly matters: your app.

Web 5 introduces DWAs to the benefits akin to those offered by cloud and application servers for enterprise apps. Simplifying the process, it handles the complexities by delivering decentralization.

With Web 5 as your foundation, your apps inherently inherit decentralization and integrated identity and data management features.

While it offers a paradigm shift in how we use and exchange data, web 5.0 is not a total overhaul of the web we already know.

It works like a progressive web application (PWA), except the decentralized web node SDK (software development kit) is added.

Then, the app is truly free to go serverless because the data is not stored with them.

There are boundless potentials for what you can create using this platform, let's explore a fantastic example.

HOLISTIC HEALTH -Medical Records app

Moving from state to state or country to country comes with having new medical personnel per state or country.

Here, Shahinaz had an Obstetrics/Gynaecologist when she travelled and gave birth in Country A back home; she has her Family Doctor who treats her privately and also a neurologist when she had mental health issues when she visited Country C.

Whenever she visits each of them, she passes through the stress of pleading with the doctor with her health record (The Family Doctor) to fax such a document to another doctor.

With Web 5.0, all she needs to do is give each of her doctors Read and Write access to the health record in her decentralized web node so that they can write those records there, saving her all the stress.

And in addition, with Web 5.0, they will all have DID. So, any doctor can see who has written the record and verify that it comes from a reputable source.

Other examples include:

• Chat Applications

• Book Review Applications

• Travelling Applications

• Music Applications

The list goes on and on. As we delve into the realm of Web5, let's embark on a journey to explore some of the prominent Web5 JS SDKs and gain a deeper understanding of the underlying Web5 protocols.

WEB 5.0 PROTOCOLS: FUNDAMENTAL PRINCIPLES AND DESIGN

Web 5.0 protocol is a document that defines a data scheme and contract by which two Decentralized Web Nodes (DWNs) agree to communicate and share data as it pertains to the scope defined by the protocol.

Two concepts are fundamental to Web 5.0 protocols:

DATA SCHEME: Protocols define our database schema or how stored data is formatted.

SHARE DATA: Protocols describe how data is shared, including who can do (read/write) what (permission).

Protocols are installed on the DWN like new syntaxes are installed on a text editor.

As such, the DWN recognizes the protocol and then is able to communicate according to the set rules.

Let's have a hypothetical example of a Web 5.0 Protocol

{
  "protocol": "https://mysite.xyz",
   "types": {
        "someType": {
            "schema": "https://mysite.xyz/schemas/someType",
            "dataFormats": ["text/plain"]
        }
    },
    "structure": {
        "someType": {
            "$actions": [
                {
                  "who": "anyone",
                  "can": "write"
                }
            ]
        }

    }
}

Breaking this down, there are three (3) parts of the protocol document that are key to understanding it.

1. "types"

2. "structure"

3. "$actions"

4. TYPES:

   This outlines all the data types used in our protocol

5. STRUCTURE:

   This details how the "types" will be nested and how they interact.

6. $ACTIONS:

   This defines who get what permissions on those "types"

In this example, anyone is given permission to write the "someType" declared under "type" to my DWN.

To further understand protocols, let's look into a practical example.

Using protocols, let's build a decentralized Twitter (d-twitter) application data schema.

Our d-Twitter goals include:

• Publish Tweet

• Read Tweets

• Reply to Tweets

• Retweet.

So, our Core Data Types are:

• Tweet

  Permission: Read and Read (past tense)

• Reply

  Permission: Write and Read

• Retweet

  Permission: Write and Read

Note: each of these data types are not going to be defined in the protocol document.

The protocol document only defines the shape of our data.

It is not going to exhaustively define every property.

These data types are defined remotely by an open schema at an ideally resolvable URL. Though, URL being resolvable is not mandatory, but that is the best practice.

The following is the life cycle/phases of a protocol document

1. Building the Protocol Document

2. Consuming (Configuring) the Protocol

3. Query the Protocol

4. Write with the Protocol

So, I will write the d-Twitter protocol document following these phases.

1. BUILDING THE d-Twitter PROTOCOL DOCUMENT

a. Declaring our Data Types

{
   "protocol": "https://d-twitter.xyz",
   "types": {
        "tweet": {
         "schema": "https://d-twitter.xyz/schemas/tweet",
         "dataFormats": ["application/json"]
        },
       "reply": {
         "schema": "https://d-twitter.xyz/schemas/reply",
         "dataFormats": ["application/json"]
        },
      "retweet": {
         "schema": "https://d-twitter.xyz/schemas/retweet",
         "dataFormats": ["application/json"]
        }

    }

}

b. Creating the Structure

{
    "protocol": "https://d-twitter.xyz",

       "structure": {
            "tweet": {
              "$actions": [...],
              "retweet": {
                "$actions": [...]
              },
              "reply": {
                 "$actions": [...]
               }
            }
       }           
}

Here, we can see that the tweet is structured in a way that it can have retweets and replies.

c. Define our Actions

{
    "protocol": "https://d-twitter.xyz",

       "structure": {
            "tweet": {
              "$actions": [
                {
                  "who": "anyone",
                  "can": "write"
                },
                {
                    "who": "anyone",
                    "can": "read"
                },
              ]

            }
       }           
}

{
    "protocol": "https://d-twitter.xyz",

       "structure": {
            "retweet": {
              "$actions": [
                {
                  "who": "anyone",
                  "can": "read"
                },
                {
                    "who": "follower",
                    "can": "write"
                },
              ]

            }
       }           
}

In this section we can see that action (permission) has been defined differently for tweets and retweets.

For tweets, anyone can read and write it, while for retweets, anyone can read it but writing attached comments to retweets is restricted only to users' followers.

Having designed or built the protocol document, the next thing is to consume it, or in other words, configure it.

1. CONSUMING THE PROTOCOL

   - CONFIGURE THE PROTOCOL

Using web5 JS SDK, the protocol can be configured (installed).

//Consume or Configure Protocol

import { Web5 } from '@tbd54566975/web5';
const { web5, did: myDid } = await Web5.connect();
const { protocol } = await web5.dwn.protocol.create({
  message: {
    definition: {
      protocol: "https://d-twitter.xyz",
       types: {
          tweet: {
             schema: "https://d-twitter.xyz/schemas/tweet",
             dataFormats: ["application/json"]
            },
            reply: {
             schema: "https://d-twitter.xyz/schemas/reply",
             dataFormats: ["application/json"]
            },
            retweet: {
             schema: "https://d-twitter.xyz/schemas/retweet",
             dataFormats: ["application/json"]
            },



        },
      structure: {
            tweet: {
              $actions: [...],
              retweet: {
                $actions: [...]
              },
              reply: {
                 $actions: [...]
               }
            }
      }          
    }
  }    

});

So, you may want to ask that what happened here?

i. The web5 js sdk is imported

ii. For const { web5, did: myDid } = await Web5.connect();

• Here a constant indicating the DID was declared

• await Web5.connect(): This determine whether the users already have DID that is local to the device they are accessing the application. If so, it will automatically ensure connection. If not, it will create a new DID and a DWN for the user.

• With this, there is no need for a username and password.

  Pretty cool right!

iii. const { protocol } = await web5.dwn.protocol.create. This writes the the d-Twitter protocol that was just built (or in the case where you are using an already built protocol for another app, it writes that existing protocol) into the user's DWN.

iv. Then everything we have under that is the protocol type structure and action that was written above (the JSON files).

This process of writing the d-Twitter protocol to the DWN is what is also termed installing. This way, I just installed the protocol.

To check if the installation was successful, the installation is queried

1. QUERYING THE PROTOCOL

To ensure that the protocol was installed, the following query.protocol method can be used.

// Query the Protocol
const {protocols} = await web5.dwn.protocols.query({
  message: {
    filter: {
      protocol: "https://d-twitter.xyz",
    }
  }
});

1. WRITE WITH THE PROTOCOL

// Write with the Protocol

const { record, status: recordsWriteStatus } = await web5.dwn.records.write({
    data: 'Hi Guys, this is my Web 5 Hackathon',
    message: {
      dataFormat: 'application/json',
      schema: "https://d-twitter.xyz/schemas/tweet",
      protocol: "https://d-twitter.xyz",
      protocolPath: "tweet"

    },
  });

We can do a simple CRUD operation with this, having built and configured the protocol document.

This explains how protocols we use are built, how we can consume built-in protocols or those we write ourselves, and how operations can be performed using protocols.

As the current web model, Web 2.0, struggles with the inherent flaws of centralized data control, the concepts of self-sovereign identity (SSI) and Web 3.0's failed promise of decentralization have paved the way for the emergence of Web 5.0. This revolutionary paradigm marks a return to the user-centric ethos of Web 1.0, where individuals regain control over their digital identities and data.

Web 5.0 stands as a beacon of hope, resurrecting the true potential of the internet by establishing a decentralized ecosystem built upon three fundamental pillars: Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and Decentralized Web Nodes (DWNs). These pillars form the bedrock of a transparent, secure, and user-empowered web experience.

At the heart of Web 5.0 is DID, a unique digital identifier representing an individual or entity within the decentralized web. VCs, verifiable assertions about an individual's credentials, provide a means to establish trust and authenticity in the digital realm. DWNs, the distributed network of nodes that maintains and secures the decentralized web, ensure the integrity and resilience of the ecosystem.

Web 5.0 protocol documents, the blueprints for building decentralized applications, provide the framework for realizing the full potential of this new web paradigm. These documents outline the phases of application development, from protocol creation and configuration to data querying and manipulation.

With the advent of Web 5.0, the web is poised for a renaissance, reclaiming its original promise of a decentralized, user-centric digital landscape. Web 5.0 paves the way for a more equitable, secure, and trustworthy internet experience for all by empowering individuals with control over their data and identity.

REFERENCES

1. Angie J., (2022). What is Web 5.TBD

https://developer.tbd.website/blog/what-is-web5/

1. Chris G.,(2023). Protocols: Basics and Design. TBD

https://www.youtube.com/watch?v=RfUE-bd73bE&list=PLji3z0eqSkXEws2wrNjyVyW3xQTW_dNlq&index=2