Guides

The Hitchhiker's Guide to Web 3.0

Rishi Raman
August 9, 2021

Unraveling the Mystery of Web 3.0

In this article, I will be examining decentralized peer-to-peer (p2p) file sharing. However, decentralized architecture is relatively new and still evolving, and the same words can mean different things to different groups, so I’ll start by outlining some general concepts and definitions, so we’re on the same page semantically.

Web 2.0 is the current iteration of the internet — it’s the framework that the vast majority of web-based applications and services use today, and it’s what most users think of as the “internet” or the “web”. The term Web 2.0 was coined in the dot com era by Tim O’Reilly and loosely defined an evolution from Web 1.0 in terms of innovations in mobile, social, and cloud computing. The idea is far more nuanced, but can be mostly encapsulated by two main evolutions — ‘services, not packaged software and ‘software above the level of a single device’.

Photo by Marvin Meyer on Unsplash

While Web 2.0 is still extremely value-creative, especially in the enterprise, we are seeing a handful of successful projects emerge from what is potentially the next internet paradigm, referred to today as Web 3.0. It is still nascent, but many believe it is the next evolution of the internet and will be the framework that defines the next era of software.

Just like Web 2.0 the definition of Web 3.0 is nuanced (still evolving, and is often defined differently by different people), but for the purposes of this article, I will simply define Web 3.0 as a shift to decentralized networks that rely on a network of peers, rather than a client-server network reliant on centralized infrastructure. We’ll get more into the details of p2p networks, but let’s first discuss why decentralization is valuable.

Decentralized networks are often more performant. Let’s look at a file-sharing use-case, where user A wants to send a video file to user B. In a centralized client-server network, the video file is uploaded from user A to a server that is downloading, and then, user B downloads the file (which the server is then uploading). The performance is limited by the upload speed of user A, the download speed of user B, the upload & download speed of the server, and the distance between each party. In a pure peer-to-peer system, the file is transported directly from one peer to another and is only limited by the upload speed of user A, the download speed of user B, and the distance between them. Accordingly, if the users and the server are all close together and the server upload/download capacity is higher than users A and B, then performance may be equal to that of a p2p network. However, as the distance between the users and the server increases and/or the performance of the server decreases (e.g. from high demand), the client-server network will perform poorly in comparison to the p2p network.

Decentralized networks are antifragile, i.e. they get stronger as additional ‘stress’ is added. As more users (peers) are added to the network, the network performance and availability actually increases. In Web 2.0 social applications, this is seen in ‘network effects: the value of the network/product increases as the network size increases. Unfortunately, this is not the case for the underlying infrastructure. As an application based on a client-server model increases in popularity, the application provider must continue to increase server capacity/central compute in order to maintain performance and availability.

Decentralized networks are trustless, i.e. the participants involved do not need to know or trust each other or a 3rd party for the system to function. Due to the client-server relationship, Web 2.0 applications are reliant on centralized servers/services, which means users must inherently trust this central authority (person or entity that owns/operates the servers), and this central authority has a unilateral ability to define the rules. In practice, this often manifests as a conflict around data ownership. For example, the popular storage and file sharing service dropbox uses a client-server model: users upload data to centralized servers owned and operated by Dropbox, and then download data from these same servers. Accordingly, all data passes through dropbox, and dropbox has the technical ability to read & copy this data. Thus, the only thing protecting a dropbox user’s data is the user agreement that they trust dropbox to abide by (and not change). In a decentralized p2p network, there is no central authority. Users are the owners and operators of their data and trust resides with the software itself (rather than the operators).

Decentralized networks are more secure. It’s in the name: peer to peer, data is directly uploaded from one peer and downloaded by the other, without the need to use a middle man (central server). This means that there is no central authority or custodian of your data (unless you choose so). Also, when there is a central authority, there is a higher incentive for the attack, since data/value is consolidated (i.e. an attacker derives lots of value from being successful once). Conversely, when data/value is highly distributed, an attacker would have to have exponentially more successful attempts in order to derive the value of the same magnitude. Decentralization reduces the incentive/payout for attackers by orders of magnitude.

Now that we have some shared context, let’s move on to discussing decentralized p2p file sharing specifically. At this point, you might be thinking “Ok decentralization sounds great, but what’s new about this? Haven’t services, like p2p file sharing, existed for over a decade?” To some extent, you would be correct, but there are some important differences between Web 2.0 p2p services and the ones we can build today on Web 3.0. Let’s take BitTorrent, which was initially released in 2001, as an example. BitTorrent has three main issues (which are solvable today): 1) it is not fully decentralized; 2) the code is not usable or extensible; 3) it lacks an incentive model.

BitTorrent (and other similar services) is not decentralized in two important ways: it uses centralized servers to track peers and store content metadata. Although peer-to-peer connections are made (in order to improve performance; i.e. by increasing the number of ‘seeders’), the instantiation of these connections requires a special server, called a tracker, which assists in the communication between peers. The tracker server also keeps track of where file copies reside on peer machines, which ones are available at the time of the client request, and helps coordinate efficient transmission and reassembly of the copied file. The use of trackers increases the COGS of the service provider and limits the privacy/security of users.

BitTorrent doesn’t have a proper incentive model. When a user begins using the service to download a file they are called a ‘leecher’, once they have pieces of the file (or if they have other files already stored that other users would like) they can become a ‘seeder’ that is also uploading files to other users. BitTorrent will prioritize downloads to users that are seeding (and users that are seeding at faster upload rates are further prioritized). However, other than this, there is no real incentive to seed or store files. Since BitTorrent is reliant on seeding and file availability, it is vulnerable without an incentive model.

BitTorrent (and similar services) have classic software usability issues that make it very difficult to leverage this previous work done. Some examples include: Lack of good documentation (or none at all), restrictive licensing (or no licensing), no easy to reach the point of contact, closed source (or the source doesn’t exist anymore), the implementation doesn’t expose a friendly API, and these projects are tightly coupled with a specific use-case. Ultimately, this means that the service’s ability to adapt and change with user needs & requirements is severely limited. In many cases, it makes it impossible to address new use cases. Specifically, BitTorrent has made some improvements (it is less reliant on trackers than in the past), but it is essentially the same service today as it was 20 years ago.

Let’s now examine Web 3.0 capabilities by continuing to use file-sharing as an example. Today, you can build fully decentralized p2p applications using protocols like Libp2p (for decentralized transport) & services like IPFS (for decentralized storage). Specifically, Libp2p’s transport protocol (via circuit relay & NAT traversal) solves the problem of connecting two peers without a special tracker server. Also, IPFS (a decentralized storage service that uses content addressing) allows for fully decentralized storage and is not reliant on either content servers or an extremely large number of live/available peers to achieve file availability.

The Web 3.0 concept of crypto/tokens solves the incentive issue. Specifically, Filecoin is a decentralized storage network that turns cloud storage into an algorithmic market. The market runs on a blockchain with a native protocol token (FIL), which miners earn by providing storage to clients. Conversely, clients spend FIL (hiring miners) to store or distribute data. Applied to a service like BitTorrent, this means that seeders would be compensated in Filecoin for storing files and making them available for download, and leechers would spend Filecoin to access them. This incentive structure would increase the incentive to seed and store files, which increases availability and performance to users. Monetary incentives also create a pathway to instantiate legitimate business models. If the file storer were able to make money, then the legitimate owners of files (media corps) might be willing to participate in the network. As Spotify proved, users don’t actually care much about the ‘free’ aspect of torrents, they care about ease of discovery and distribution.

Most importantly, entities like Protocol Labs are solving software usability issues. They are the creators of Libp2p, IPFS, and Filecoin. All three of these projects are open-source, have up-to-date documentation, and are supported by a team that is reachable. Additionally, protocols like Libp2p are highly modular and built for general-purpose use. This means that products built with Libp2p are highly extensible, and can change rapidly to address evolving user needs and new use-cases.

In summary, decentralized p2p applications have many native benefits (especially in terms of performance and security), and now tools and infrastructure are in place to build robust p2p applications, which brings me to the reason I’m writing this article: the beta release of Sonr.

Sonr is a pure peer-to-peer (decentralized) file-sharing application. Think of it as a cross-platform airdrop that works with any file size, under any network conditions, at any distance. It is built with Libp2p and may incorporate IPFS/Filecoin or other decentralized storage networks in the future. I will be writing more on Sonr specifically, in upcoming articles.

About the author

Our latest news

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Non eget pharetra nibh mi, neque, purus.

Ready to get started?

Start Free Trial