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

Imagine a virtual tapestry woven with threads of innovation, where the once stationary digital landscape now pulsates with life, intelligence, and interconnectivity.

It's a saga that unfolds through epochs, from the rudimentary pages of Web 1.0 to the social dynamism of Web 2.0 and the decentralization of Web 3.0. Yet, amidst this evolutionary narrative lies a mystifying leap, Web 4.0, a ghostly chasm shrouded in speculation.

Embark with me on an expedition through this digital odyssey as we unveil the pivotal leap "From Static to Smart," delving into the transformative ascent to Web 5.0 and the uncharted territories beyond, where intelligence converges with innovation to reshape our digital universe.

THE EVOLUTION: FROM STATIC TO SMART

The evolution of the internet, from its rudimentary static pages in the era of Web 1.0 to the dynamic and interactive landscape of Web 3.0, mirrors a staggering journey in the digital realm.

Web 1.0 ushered in the internet's infancy, characterized by static web pages and limited user interaction. It was an era where information consumption reigned supreme, offering a glimpse into the digital future.

However, the transition to Web 2.0 marked a significant paradigm shift, introducing user-generated content, social media platforms, and interactive experiences, propelling the Internet into an active participation and collaboration era.

Yet, the emergence of Web 3.0 serves the smartest and most user-oriented of this evolution, introducing decentralization, interoperability, and a smarter, more autonomous web.

Now, standing at the cusp of innovation, Web 5.0 envisions a future where Web 2.0 principles of user-generated content, social media platforms, and interactive experiences are augmented by Web 3.0 principles of decentralization, interoperability and a smarter, more autonomous web.

The trajectory from the static origins of Web 1.0 to the intelligent prospects of Web 5.0 symbolizes a remarkable journey in the evolution of the internet, each iteration marking a transformative leap toward a more connected, intelligent, and user-centric digital frontier.

THE TIMELINE: WEB 1.0 - WEB 5.0

Image Credit: Toyyib Muhammad-Jamiu

1991-2004: WEB 1.0 - THE READ-ONLY WEB

Web 1.0 serves as the initial overview of what the internet was.

• The first iteration of the web

• Mostly static, non-interactive pages

• There are no signups nor Logins and no interactivity whatsoever

• Mostly a big wikipedia all linked together with just text and images ( bland at its best 😅)

• At this time, users were consumers (i.e., users had autonomy over their data but could only interact with the static pages in front of them).

2004-DATE: WEB 2.0 - THE SOCIAL WEB

Web 2.0 marks a significant evolution from the static, one-way communication of Web 1.0 to a dynamic, interactive online environment.

Unlike its predecessor, Web 2.0 fosters user-generated content, collaboration, and social interaction. It introduces a shift from mere consumption to active participation, empowering users to create, share, and collaborate on content through social media, blogs, wikis, and more. This iteration revolutionizes the internet experience, emphasizing community, interactivity, and user engagement.

The emergence of Web 2.0 amplifies connectivity, facilitates information sharing, and enhances user interactivity, laying the groundwork for a more engaging and collaborative online ecosystem.

EXPLORING LIMITATIONS AND CHALLENGES IN THE AGE OF CENTRALIZATION AND DATA PRIVACY CONCERNS

Web 2.0, despite its transformative impact on user interaction and content creation, unveils inherent vulnerabilities. Its Achilles' heel lies in centralized control, fostering data monopolies, and privacy concerns. This paradigm, marked by platform dominance and data exploitation, raises significant challenges in safeguarding user privacy and autonomy.

Now, let us understand how Web 2.0 falls into these shortcomings.

Many companies do not start by launching apps aiming to collect user data and make decisions on this data without users' consent.

It starts when companies raise Venture Capital 😏.

When a company building an app raises venture capital, its investors often expect a return on investment (ROI) in 10s or 100s of their deposit.

This means that companies are often pushed down two paths: promoting or selling personal information instead of choosing a sustainable growth model that can be maintained more organically.

More data for many Web 2 companies, such as Google, Facebook, and Twitter, leads to more personalized advertising. This will increase clicks and, ultimately, advertising revenue.

In Web 2, you can not control your data or how your data is stored. Companies often track and store user data without the consent of the user. The company responsible for these platforms owns and manages all of these data.

Governments often shut down servers or confiscate bank accounts if they believe a person is expressing an opinion that contradicts the publicity.

An example was the one witnessed in Nigeria in 2021, where Nigerians could not use Twitter due to the Twitter ban.

The ban occurred after Twitter deleted tweets made by, and temporarily suspended, the Nigerian president Muhammadu Buhari, warning the Eastern people of Nigeria, predominantly Igbo people, of a potential repeat of the 1967 Nigerian Civil War due to the ongoing insurgency in Southeastern Nigeria.

Centralized servers make it easy for governments to intervene, control or shut down apps at their sole discretion.

Banks are also digitally centralized, so governments often intervene. They may block access to bank accounts or restrict access to funds during periods of volatility, extreme inflation or other political turmoil.

The Nigerian no-cash policy enforcement by the Central Bank of Nigeria in April 2023, where citizens have access to less or no cash due to the implementation of the use of new Naira notes and banning the old naira note as a legal tender, is another example that bolsters the fact that centralized servers of the web2.0 internet used by banks deprived citizens of their money and made it seem as though it was not theirs.

The need for a more decentralized, secure, and user-centric web becomes imperative in navigating these critical limitations of Web 2.0.

Web 3.0 addresses many of these shortcomings by fundamentally rethinking how to build and operate applications from scratch.

2014-DATE: WEB 3.0 - THE DECENTRALIZED WEB

• Gavin Wood, founder of blockchain infrastructure company Parity Technologies and the co-founder of Ethereum, coined the term “Web 3.0” in 2014, laying out his vision of the future of the internet.

• Web 3.0 is a decentralized version of the internet , it is not dominated by a handful of influential players such as Amazon, Microsoft and Google.

• Web1 aimed for an open, decentralized internet, but Web2 - the internet we know today, birthed trillion-dollar tech giants, wielding immense influence and owning much of the web's infrastructure.

• In 2014, when being interviewed on the Beyond the Valley podcast, Gavin Wood said: “The big problem with this is sort of the same thing as placing all your eggs in one basket; if something goes wrong with one of these services, you know, the service is suddenly unavailable for an awful lot of people”.

• Web 3.0 decentralization concept ensures user autonomy over their data.

• Blockchain, often linked with bitcoin, is a pivotal technology underpinning Web3.

• The Bitcoin blockchain serves as a public ledger of the activity of the Bitcoin network.

• It operates without centralized ownership or control, functioning through decentralization and maintenance by a global community using specialized computers.

• Web3 thrives on a 'trustless' concept, aiming to rely less on company assurances.

• This, in turn, means that with decentralized products on blockchains, trust primarily rests on the algorithm ensuring service delivery.

• In Web 3.0, developers typically build and deploy apps that run on a single server or store data in a single database, usually hosted and managed by a single cloud provider.

• Web 3.0 apps are often called DApps (Decentralized Apps), distributed, open-source software applications that run on a peer-to-peer (P2P) blockchain network rather than a single computer.

• Cryptocurrencies play a significant role in many web 3.0 protocols.

• They provide financial incentive tokens to anyone who wants to be involved in creating, managing, supporting or improving a project.

• In Web 3.0, the money goes directly to the Network participants.

• This way, just like many forms of decentralization, unnecessary and often inefficient intermediaries are cut out.

WEB 5.0- AN OVERVIEW

On June 17, 2022, a remarkable event happened. Jack Dorsey, the former Twitter CEO announced a new platform on Twitter called ‘Web5’, a combination of Web 3.0 and Web 2.0.

Web5.0 is an open source decentralised web platform championed by TBD. TBD said on their website following the announcement of Web 5, “We struggle to secure personal data with hundreds of accounts and passwords we can’t remember. On the web today, identity and personal data have become the property of third parties”.

The platform brings decentralized identity and data storage to applications. “It lets developers focus on creating delightful user experiences while returning ownership of data and identity to individuals,” according to the company.

Within the web framework, individuals must gain ownership of their data and identity. Companies furnish users with accounts, confining their data within application silos. To foster a novel category of decentralized applications and protocols centred around individuals, empowering users with self-owned identities and reinstating their authority over data control is essential.

Why Web 5 again when Web 3 is based on this principle?

Worry less, I was there before, but have clarity now.

WHY WEB 5.0

Web3, touted as the decentralized internet, faces a glaring issue upon closer inspection. It lacks the decentralization it purports to embody. Many applications and protocols within Web3 lean towards centralization, primarily controlled by venture capitalists and influential entities within the blockchain space.

And even according to Jack Dorsey (Former Twitter CEO), Web3 is not decentralized, and it’s just like Web2, which is also centralized but with a different label.

In December 2021, he tweeted, “It’s ultimately a centralized entity with a different label. Know what you’re getting into.”

A vocal critic of Web3's centralization concerns, Jack Dorsey recently unveiled a potential solution: "Web5." Introduced through TBD, a division under Dorsey's Block Inc. (previously known as Square).

What Is Web5?

For starters, the idea of Web5 was brought up when TBD, a company of Jack Dorsey’s Block Inc. (formerly known as Square), announced it on Twitter, with the aim to even be extra decentralized using the Bitcoin layer two solutions, which is the lightning network.

The concept behind Web5, as outlined in TBD's shared document, revolves around enabling decentralized applications and protocols, positioned as an evolution beyond the questionable decentralization of Web3.

Web5 will make use of digital wallets and will also bring a Decentralized Web Platform (DWP), which will then enable developers to write Decentralized Web Apps (DWAs) using Decentralized Identifiers (DIDs) and Decentralized Web Nodes (DWNs) to return ownership and control over identity and data to users.

This is basically what Web5 is all about. Helping developers develop decentralized Web Apps to help users own their data and control their identities using Decentralized Web Nodes, also known as DWN.

Someone might be wondering.

Ok, I understand now, and it's been a nice read. I understand the reason why web5.0 is in place.

In all of this, why did we skip Web 4.0? Why did the next evolution get labelled 5.0? At least in normal Mathematics, integers follow that sequence: 1, 2, 3, 4, 5. Why do we now have Web 1.0, 2.0, 3.0....5.0 😩

Do not fret, I got you covered

Web3, Web5, and the Enigmatic Skip: Unraveling the Mystery of Web4's Missing Evolution

The truth is that TBD or Jack Dorsey was not interested in keeping the version or name in order. They just went and called the new idea Web5.

It’s not about them not wanting to keep it in order; they just wanted to illustrate how Web2 + Web3 = Web5.

Image credit: tbd

So they did a bit of Mathematics there, that is, 2+3 = 5.

So yeah, that’s pretty much what it’s about.

So Web4? It seems it didn't have its turn; it was simply skipped. Perhaps it wasn't the lucky number 😅.

The evolution of the web has been a transformative odyssey, starting from the static pages of Web 1.0 and blossoming into the interactive and user-driven landscape of Web 2.0.

The subsequent leap to Web 3.0 heralded decentralization and connectivity, empowering users in unprecedented ways.

Now poised at the brink of innovation, Web 5.0 beckons an era of true decentralization and interconnectedness. Each iteration, from Web 1.0 to Web 3.0 and the newer Web 5.0, signifies a quantum leap in technological advancement, reshaping our digital universe towards a smarter, more interconnected future.

In the next episode, I will dissect how Web 5.0 works and demonstrate how to build an app using the Web 5.0 toolkit. Stay tuned.

REFERENCE

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

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

2. Arjun K.,(2022).What is ‘Web3’? Here’s the vision for the future of the internet from the man who coined the phrase.CNBC

   https://www.cnbc.com/2022/04/20/what-is-web3-gavin-wood-who-invented-the-word-gives-his-vision.html

3. Samuel E., (2022). Web3, Now Web5? What Happened To Web4? Coinmonks.

   https://medium.com/coinmonks/web3-now-web5-what-happened-to-web4-596adce6564