unstoppable sites in the web3

I have been playing this weeks with deploying decentralized applications. Doing a bit of analysis on the landscape. What are the existing options, the challenges they face and the stage of the different parts. What would be a decentralized web3. Moving some of my notes into articles.

How do they work now?

Let’s take a step back and check how the web2 works. You have a DNS, Domain Name Service, a service able to translate IP addresses into human-readable addresses (i.e. “yahoo.com”). When you ask for a site, your ISP handles that request. Routing it to the entity you are looking for and retrieving the packages said entity sends back to you (data).

All this game of interactions. Between your computer, the application you are using, your ISP, servers, etc, is abstracted. To create a more user-friendly experience.

Here you have a nice graph (not mine) of how all that works. It is of course a simplification, we have built a lot of infrastructure over the years to deliver a great experience (CDNs, containers,…). You get the idea.

How do decentralized domains work then?

How do web3 works? We have a similar problem. For starters, wallets have long, unfriendly addresses. Hard to memorize, share and prone to typing errors. We have Unstoppable Domains and ENS, Ethereum Name Service, whose job is to “translate” those into something easy to type and remember. Both allow multiple wallets in different coins (ETH, BTC, LTC, DOGE). As Well as add different records (content, discord,…). Allow you to point your domain to a site.

There are differences and similarities around how the registration process works. Price models, how ownership is handled, etc, but will not go there. The main difference between both services is their business model. ENS has a yearly payment structure, while UD has a one-off payment model. Not fundamentally relevant, but worth remembering.

The main caveat right now is that you need to use applications that work with said domain extensions.

The ICANN has not introduced those domain extensions in the standard. Regardless of how you host your site, your audience will still need a browser supporting your “special” domain (Brave). Alternatively, extensions that help you load crypto-related domains. It is very unlikely they will be incorporated natively in the future. Their creation and ownership are completely out of the control of the ICANN. A strong barrier to adoption, although not a definitive one.

What is the promise?

The promise is to have a decentralized web. Meaning your site infrastructure is not dependent on private entities, but organized in a way that your content would be theoretically more resilient. Your data cannot be taken down, disappear or be regulated.

This would enable to have always available information, reliable. Escaping the censorship in authoritarian governments. We all know the dark side of said promise as well, the dark web, the uncontrollable spread of fake information… Aspects not limited to a pure societal rejection, but also having strategic value. Being susceptible to manipulation according to particular interests. Weaponizing information is not new, but the scale and reach are.

Another aspect to take into account is that complete anonymity is not possible. Even not providing your personal information when registering. You are still leaking details about your wallet, IP address, etc.

The elephant in the room is they are still pretty much centralized. As they are now at least. First, you need the central organization (ENS, Unstoppable Domains) to provide the domain. You also need a said entity to allow the association with a particular coin or asset. Second, you still need a third-party browser or extension to route to your domain. Meaning that, as example, Brave could tomorrow decide to block your particular site and no user will be able to easily reach your content.

Great teams are working on providing the other (more significant) significant parts of the equation in an almost decentralized shape (message routing, container resolving,…). Making it possible running on-chain applications. I promise I will write more about all the work done by the IPFS and the Internet Computer protocol.