Block’s TBD54566975 team recently published a blog post explaining the “Web5” project they announced earlier. Web5’s objective is to return ownership of data and identity to individuals. As we have seen how the tech giants gained unchecked power over the people on the internet in recent years, this project’s objective is no doubt alluring. However, I think the current design of Web5 is unable to answer several important challenges we have seen from early web decentralization projects.

Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.

At a high level, the components of Web5 include Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and Decentralized Web Nodes (DWNs). And these components are connected and made available to application developers to build Decentralized Web Apps (DWAs) using Web5’s SDK.

The center of the architecture is Decentralized Identifiers. It is a representation of a user, and it is used to resolve a user’s DWN. DID is analogous to DNS. Instead of DNS that looks up the IP address of a web server, DID looks up the location of the DWN of user identity. This component is what actually makes identity and data portable.

Verifiable Credential is a mechanism to assert statements about a user via digital signatures. For example, a bank could produce a VC document that certifies a DID is their customer. The owner of the DID could use the VC document to prove to anybody that he has an account in that bank.

DID and VC are both W3C standards that existed before Web5. What makes things interesting is the Decentralized Web Nodes. DWNs are servers that host user content and decouple data from the application software. As such, users need to bring their own DWN to use web5 applications. Users typically operate the DWN on their home server or subscribe to a hosting service. DWNs can hold both public and private (encrypted data), and the user control who can access what.

Contrary to many people characterizing Web5 as a decentralized system on top of Bitcoin, Web5 is neither a blockchain nor stores user data on a blockchain. None of the above components live on a blockchain.

The confusion was probably due to Web5’s relationship with the ION project, a DID network that runs on top of Bitcoin. TBD mentioned ION is a preferred design for the implementation of Web 5. But indeed, ION is not a requirement. According to TBD’s blog post, any implementation that conforms to the DID standard will work in Web5, including Ethereum Name Service (ENS) and the good old DNS.

Besides ION, Web5 has no relation to a blockchain at all. And of course, there are no tokens in Web5.

https://twitter.com/brockm/status/1535328599200477184

The main idea of Web5 is not novel. We can find its root in the decentralized web and semantic web concept that has been around since the early 2000s. Several prominent web decentralization projects have been built on the same idea, such as Unhosted (2010) and Tim Berners-Lee’s Solid (2016). (I contributed to the Unhosted project many years ago.)

The design of these earlier web decentralization projects is very much the same as Web 5. The general idea is to decouple the data and identity from the applications that users use. These projects build generic data and identity layers that are expected to support a wide range of applications.

So, instead of publishing content to services like Facebook, Twitter, or YouTube, users host their content on their own data storage and identity service. Permissions are given to applications or platforms to display the content. That means users are responsible for hosting their tweets and videos and keeping them available.

The idea is that these web decentralization architectures enable users to switch application vendors or storage service providers easily. Users can enjoy the convenience of social networks and cloud software without giving up their control and ownership of their data and identity.

In the end, neither Solid nor Unhosted gained significant mass market adoption. Maybe it is too early to say whether Web5 will share the same fate, but for it to make any difference, it is important to look at what lessons the past decentralization projects (and the early internet) teach us.

The early builders of the internet shared a strong ethos of decentralization. Thus, separating servers and application clients was actually the norm in early internet protocols. Email is one of these protocols. And it is a prime example of the problems faced by building decentralized systems today.

In the early days, we had email servers and clients developed separately by different vendors. It was normal to use Pine or Microsoft Outlook with a Linux mail server or Thunderbird with Microsoft Exchange Server because they talk to each other using open protocols such as IMAP. As a user, being able to switch to different applications easily without fear of losing years of email conversations was really nice.

Back in the early 2000, there was a vibrant market for email services. There were a lot of different companies that built email clients and provide email hosting services to the public. That period probably was the peak of internet decentralization. However, by late 2000, most of these companies were shut down or pivoted into other businesses. More consolidated services like Gmail prevail.

A reason for the internet to become more decentralized is the gigantic shift of web monetization models to advertising.

Many early email service providers were free or charged users monthly subscriptions and software licensing fees. However, because these companies used the same set of protocols, they were largely indistinguishable from their customers’ perspectives. The result is fierce price competition between them which limited their profitability. These companies also have little incentive to innovate because it was hard for them to capture value from an open protocol.

What followed the shifting to the advertising model was centralization. Need to show ads to users? Own the client application. Need to give advertisers larger audiences to reach? Own the servers and users’ identities to make your users harder to switch.

A more centralized architecture also makes companies easier to build new features and improve the user experience because they no longer need to align with different stakeholders to change the protocol for new functions. They can respond to users’ needs much faster, making the decentralized counterparts an uphill battle to compete. And because of the strong network effects in advertising, services are forced to become more consolidated.

Today, the client-server separation of email is basically dead. But interestingly, email remains one of the last internet protocols that still keeps most of its decentralization characteristics from the early internet. Running your email service, although becoming a less popular option, is still feasible. Users on different email services can still talk to each other agnostic to the service providers.

Solid, Unhosted, and Web5 both focus on supporting web applications on their decentralized platforms. Web5 envisions applications becoming completely serverless because the data isn’t stored with them.

This stance made sense for Unhosted when it first came out in 2010 when most of our computing was still on the desktop and the web. However, we are in 2022 now. Mobile internet usage has long passed desktop, and the trend is pretty clear that most of our internet activities will be mobile. A decentralization platform that cannot deliver a great experience on mobile is doomed to failure.

The web platform surely has improved by a great deal. Progressive Web Apps are much more powerful than what could have been done ten years ago. For example, today’s web apps can store gigabytes of data on the client side and perform peer-to-peer communications between clients. Many popular desktop apps are built on the web platform, like VSCode, Slack, and Discord. However, the PWA experience on mobile is far from ideal. On the mobile web, web features are often missing, suboptimal, or lagging for several years. The truth is, supporting a great PWA experience is understandably not a priority for Apple and Google. As long as they have tight control over their mobile platform, PWA will continue to be a second-class citizen on mobile.

What developers usually want is to build cross-platform applications that deliver the best experience. It doesn’t really matter whether it is a web app or a native app. Platforms like React Native enabled developers to have the benefits of both sides. Many developers prefer these cross-platform app development platforms over the PWA because they give developers more control and capability.

Of course, the Web5 protocols are not necessarily web specific. Native apps can use the same protocol to access users’ data from a DWN as well. However, the vision that applications become complete serverless and rely on generic data storage servers is so counter-intuitive with today’s mobile-centric internet. Because mobile phones generally have limited storage and battery life, a lot of computation that could have been done on the client side has to be moved to the servers to create a sleek user experience on mobile.

For example, when you search emails on a desktop email client like Thunderbird, the indexing and searching of emails are often done on the client. Because IMAP’s search function is very limiting and slow, desktop email clients can offer a far better search experience by downloading all the emails and indexing them locally. However, the same thing cannot be easily done on mobile because of the constraints. As a result, email clients that perform searching on servers like Gmail offer a better experience than the built-in Mail App.

A do-it-all protocol does not fit the needs of a mobile-centric internet. Because server-side functions are application-specific, it is difficult to predict what is needed and design a small set of features that can meet the demand of different applications. And even if we can extend the Web5 DWN standard to support more application types, it may be undesirable as the standard will soon become overly bloated. It will result in fragmented implementations because no single software can support all the extensions created and maintained by hundreds of parties. This situation had happened to highly extensible open standards like XMPP. The fragmentation has led to platform consolidation again because it creates a lot of problems for users and software maintainers.

Most internet users are not interested in decentralization, they are using the internet for cute cats. And given a choice between dancing pigs and security (or privacy), users will pick dancing pigs every time.

In reality, decentralization or not doesn’t really matter. If ever there is a successor to web 2.0, it must be a platform that allows us to share and see the most number of lolcats. Arguing which network or architecture is more decentralized is a waste of time.

It doesn’t mean a decentralized web will fail. In contrast, I believe the benefit of decentralization is the freedom that maximizes our generativity and creativity without turning us into slaves or addicts. Therefore, it will be a platform that allows us to share more cat photos. We just need to be more clear about why we are building it.

The architecture of the internet is determined by the prevailing revenue model. On web 2.0, the winner was clearly the advertising business. It results in a centralized internet that maximizes user attention and turns it into revenue. The challenge for web decentralization is to create a system that permits sustainable business models other than advertising. If the next generation of the web is still powered by advertising, we can be sure that the same problems in today’s internet will happen again.

And I think Web5 does not yet have an adequate answer to the problems.

If you find this article interesting, please follow me on Twitter.