My thoughts on Web5
Or why decentralized web failed
Block’s TBD54566975 team recently published a blog post explaining the “Web5” project they announced earlier. As tech giants gaining power and placing more restrictions on what users and developers can do, Web5's objectives of returning ownership of data and identity to individuals is no doubt appealing.
There were many driving forces that pushed the internet from decentralized to centralized: economies of scale, monetary policy, venture capitals, mobile, spams, abuses, to name a few. To build a decentralized system aiming at mass adoption, the creator must tackles problems beside merely offering technical capability.
I would like to drill down into a few aspects that are concerning the design of decentralized webs, and explain why I think Web5 is inadequate to achieve the goals of buiding one.
What is Web5
Web 5 is a decentralized platform that provides a new identity layer for the web to enable decentralized apps and protocols.
The center of the architecture of Web5 is the Decentralized Web Nodes. DWNs are servers that host user content and decouple data from the application software. As such, Web5 expects users to bring their own DWN to use web5 applications, either on their home server or subscribe to a hosting service. DWNs hold both public and private (encrypted data), and the user controls who can access what.
The main idea of Web5 is not novel. It is rooted in the decentralized web and semantic web concept that have 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). (Disclosure: I contributed to the Unhosted project many years ago.)
Web5’s design is very much the same as the earlier projects. The general idea is to decouple data and identity from the applications. It enables users to switch application vendors or storage service providers easily, allowing them to enjoy the convenience of social networks and cloud software without giving up their control and ownership of their data and identity.
Contrary to many people characterizing Web5 as a blockchain system, Web5 is neither a blockchain nor storing user data on a blockchain. The only part of Web5 that touches blockchain is the Decentralized Identifiers (DIDs). Although TBD named ION, which is on top of Bitcoin, as a preferred DID design for the implementation, ION isn’t a requirement to use Web5. The DID essentially acts a pointer for looking up information about an identifier (a person, a company, or any object) off-chain. Any implementation that conforms to the W3C DID standard will work in Web5 we well, including Ethereum Name Service (ENS) or DNS names.
In the end, neither Solid nor Unhosted gained significant mass market adoption. You may say it is still early for Web5, but can it avoid the same fate? Perhaps we could learn a lesson from the early decentralization protocols.
The past failures of web decentralization
The early builders of the internet shared a strong ethos of decentralization. Thus, decentralization was indeed the norm in early internet protocols, such as the internet itself, email, the World Wide Web, CalDAV, Usenet, RSS, and XMPP.
Over the last 20 years, the number of global internet users exploded from only 413 million in 2000 to over 3.4 billion in 2016. The internet didn’t become more decentralized and democratic as some idealists predicted. Instead, centralized counterparts offered by large corporations have taken over many of these early decentralized protocols, and today’s internet has a lot more restrictions placed by the internet oligopoly.
Why did these early protocols, once very popular, outcompeted by centralized counterparts in recent years? I think these are some important questions should be answered by any builder who want to create a decentralized internet that is relevant.
Lack of monetization
As a typical decentralized system from the early days, email is our best example to illustrate the issues.
In the early days, email servers and clients are all interoperable. Email servers use SMTP protocol to exchange emails with each others, and email clients use another protocol such as IMAP or POP3 to download emails to end-users’ computers. Different vendors created these server and client programs, but since they talk to each other using standard protocols, it was perfectly fine to use Pine or Microsoft Outlook with a Linux Sendmail server or Thunderbird with Microsoft Exchange Server.
There was a vibrant market for both email clients and server hosting services back in early 2000. However, by late 2000, most of these companies were shut down or pivoted into other businesses, ousted by more consolidated services like Gmail.
One reason was the lack of monetization for the email hosting service providers.
Many early email hosting providers were free or charged users monthly service fees. Because all email hosting companies use the same set of protocols, they were largely undifferentiated from their customers’ perspectives. The result is fierce price competition which severely limits their profitability.
Following the gigantic shift of web monetization models to advertising, email providers who control both the servers and the clients such as Gmail and Hotmail quickly took off because they are able to show ads and therefore provide services for free to users. Also, controlling the clients incentivizes the providers offer unique features to differentiate from competitions and improve the overall UX.
Today, all large email services provides their own tightly coupled clients to users. The client-server separation of email is essentially dead. Interestingly, email is still an interoperable system in the sense that users can send emails across different service providers. Running your own email server, although becoming a less popular option, is still feasible. The current state of email shows that sustainable decentralized systems need to offers enough opportunities for companies to monetize over it.
Subpar mobile experience
Solid, Unhosted, and Web5 both focus on supporting web applications on a decentralized platform. Web5 envisions applications becoming completely serverless because the data isn’t stored with them.
Focusing on web may made sense for Unhosted in 2010 when most of our computing was still on the desktop and the web. However, in 2022, it is pretty clear that most of our internet activities have already been shifted to 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. However, the PWA experience on mobile is a second-class citizen. On mobile, web features are often unsupported, suboptimal, or lagging for several years. With Apple and Google holding tight control over their mobile platform, supporting a great PWA experience will never become a priority for them.
Of course, the these decentralized application platforms are not necessarily web specific. Native apps can use the same protocol to access users’ data from a storage server as well. However, the vision that applications become complete serverless and rely on generic data storage servers is still awkward with the trends of mobile application architecture.
A lot of computation that could have been done on the client side has to be moved to the servers to create a sleeker user experience on mobile devices because they have limited storage and battery life.
Back to our email example. Desktop email clients like Thunderbird search emails by downloading all the emails and indexing them locally. Because IMAP’s search function is very limited and slow, this approach provides a much better user experience. However, mobile email clients do not have the luxury for this amount of client-side processing. Hence, tightly coupled email apps like Gmail perform searches using private APIs, allowing them to provide better experience than the built-in Mail App that use standard IMAP protocol.
You may say why don’t we design a protocol that is so extensible to allow mobile apps to off-loading intensive computation to the server? Then, we have the next problem.
Feature creep
Many protocols were ambitious about being a do-it-all protocol that offers a multitude of different applications, and XMPP is one of them. XMPP is a highly extensible open protocol for instant messaging. It was once a very popular protocol. Even WhatsApp, Facebook Messenger, and Google Chat used it at some point. Designed to be so extensible, XMPP offers many features beyond simple IM, including signalling for VoIP, video, file transfer, gaming and many other uses.
Lacking a clear direction and too much extensibility, XMPP quickly became overly bloated. There were a lot of applications and every stakeholders wanted its features to be prioritized. The result was a high cost to maintain and change the protocol. And it caused implementations to be fragmented because no single software can support all the extensions created by hundreds of parties. The fragmentation of XMPP creates a lot of problems for users and software developers, which eventually causes them to the abandon the protocol and opt for alternatives that offer more simplicity.
A simple protocol that is flexible and able to move fast is far better at adapting to environment than a protocol that support hundreds of different applications at the same time.
Users don’t care about decentralization
We must accept that most internet users are not interested in decentralization. They are using the internet for cute cats. And given a choice between dancing pigs and privacy, users will pick dancing pigs every time.
What is important is that we want a web platform that allows us to share and see the most number of memes and lolcats. The question is what architecture offers this without turning us into slaves or addicts? Decentralized web is relevant because it offers the least restriction to users and developers to fully capitalize the creativity of human.
In reality, decentralization is inconsequential. Arguing which network architecture is more decentralized is a waste of time.
If you find this article interesting, please follow me on Twitter.