Web3 means Freedom Software

It's been over 10 years since the inception of Ethereum and the idea of web3 as a decentralized internet. Yet it seems like we've made almost no progress towards achieving this elusive "web3" thing. So what went wrong? There were so many builders that were excited about this new future of the internet. Somewhere along the way we lost track of what web3 is supposed to enable: a self-sovereign computation stack that sets people free. Much of this can likely be attributed to heavy venture investments in the space, and subsequent embedded growth obligations (EGOs) that force startups to abandon the principles upon which they were founded.

Perversion of the Landscape

While EGOs represent a core part of the moral rot of web3, a second-order effect is that the end users of web3 products have no idea about the actual value proposition of these products. This is because EGO-driven ventures have an incentive to describe web3 with a narrative that fits their growth goals rather than web3's real purpose, leaving end users confused and ultimately disillusioned (the "web3" product is actually worse than the web2 service it replaces). For a large number of people, not only do they not get the true freedom that web3 was supposed to bring, they never even truly learn that these freedoms exist. More importantly, they don't ever learn what they are supposed to look for in order to distinguish a proper web3 product.

So what is Web3 Actually?

If you are philosophical in nature, a good place to start in terms of understanding the principles that should enable web3 is the concept of CROPS, that the Ethereum Foundation recently published. The abbreviation is broken into four main pillars:

Censorship Resistance - No one should be arbitrarily blocked from accessing the system
Open source and libre - Software should be created and distributed freely (free as in freedom)
Privacy - The private information of the users should be protected and it should always be up to the user to decide what to share and when
Security - The software should do what it says, no less, no more

These principles are great, but they are very abstract and don't really help the average person understand what software that respects freedom (web3 software) really looks like. But there are lots of fantastic examples of tools and communities out there. So the rest of this article will be dedicated to highlighting some of these.

Preservation of Culture

Growing up, the first time I got in contact with cypherpunk culture was through sharing music. At first through borrowing CDs from friends and making copies, but as our appetite grew and technology advanced, we quickly realized we could access far more music online. The Pirate Bay was the website of choice, and sharing all kinds of cultural artifacts soon became second nature. Through the peer-to-peer BitTorrent protocol and indexers like The Pirate Bay, everyone has the freedom to contribute to the largest and most readily available cultural archive in human history. In my opinion, The Pirate Bay is the most successful web3 product ever created.

Beyond mainly entertainment media, we have a set of applications focused on creating open digital libraries. Sci-Hub archives most scientific articles that have ever been published. This is a critical task because, unfortunately, most publicly funded science ends up being published in pay-to-read scientific journals, completely shutting out everyone who can't afford expensive subscriptions to browse and learn contemporary science. Library Genesis is an extensive collection of e-books that has enabled anyone to access books for free. There have been numerous instantiations of LibGen where different operators have re-published the archive because an old site had been taken down, showing the resilience of open digital archive efforts. Anna's Archive is a newer and larger effort that brings Sci-Hub, LibGen, and other shadow libraries together in a searchable database. These projects obviously live in legal and moral tension with current copyright regimes, but that tension is part of what makes them useful examples: censorship resistance matters most when powerful institutions want to restrict access to culture and knowledge. Additionally, anyone can contribute to making the storage of these cultural artifacts more resilient by seeding their torrents using the BitTorrent protocol.

Wikipedia gets an honorable mention here because it's also easy to copy. Projects like Kiwix make it easy to distribute in a completely offline manner. This is crucial for more remote areas without internet access or during connectivity outages.
Unfortunately, Wikipedia isn't exactly censorship resistant, and the moderator community certainly has specific biases.

Open Source Software

While being open source (and ideally some form of copyleft) is a requirement for anything to truly be considered web3, being open source software doesn't really make something web3. For example, you could make an open source surveillance system for governments, which clearly doesn't uphold the CROPS principles. It's worth pointing out, however, that some open source software is fundamental to enabling web3 at large, even if that's not their aim. The key example of this is, of course, Linux. It's essentially a way for you to use your computer without being locked into Microsoft or Apple's proprietary software ecosystems (which comes with a variety of problems). Linux, through its wide variety of distributions, allows you to take full control of your computer and get around any silly restrictions that your government might want to put on computation (e.g. the recent mandatory age verification for operating systems).
Generally, open source software tends to be aligned with user freedom and control. Once you install an application it will be on your machine forever (or until you remove it). No one can take it from you. This is something where I think the web3 community needs to learn from. Maybe web3 apps so far have been hosted on the web, where DNS and servers are centralized points of failure. For this reason, I think it makes sense to consider the open source ecosystem as an integral part of web3, because it shows us a better path!

Self-hosting

Beyond just software that you run on your own computer, there's also a large amount of software you can run on a server that enables you and your friends to be more free. There is a huge set of apps you can self-host, the list below is simply some of the software that I have enjoyed using. The point of these examples is not that every self-hosted app is automatically fully web3, but that self-hosting often makes the CROPS properties concrete in practice: it increases user control, improves privacy, and reduces dependence on centralized gatekeepers.

Immich

Many people are very sentimental about their photo collections and are quite locked into the convenience of Apple or Google Photos. There, your photos are easily available and backed up in the cloud. Immich is a self-hosted alternative photo infrastructure, provided in a very polished app. You install it on your phone and it automatically backs up photos to your server as you take them. It works across Android, iOS, and the web. You can also invite your friends and family to make shared photo albums, which would have been impossible previously if they were scattered across iOS and Android.

OwnCloud

There's quite a few self-hosted file storage solutions out there. They all compete with the likes of Dropbox, Google Drive, and iCloud. Their benefit, of course, is that you fully control all of your files, and no third-party company or government can access them without your consent. I ended up using OwnCloud (or more specifically OwnCloud Infinite Scale, which is a rewrite of their codebase to be more modern) because other systems either tried to do too much, too little, or were not easy enough to use (e.g. if I wanted to onboard non-technical friends).

Arr Stack

The appropriately named *arr stack is a set of self-hosted tools that make it easier to manage the culture you are sharing using torrent files. Ideally this is something that you run on your media center, connected to your big screen and speaker system. You start off with the headless BitTorrent client rtorrent, connect that to a web interface like rutorrent, and finally make sure your downloaded media ends up in a folder controlled by your media center interface, e.g. Kodi. Then you probably want a better way to add torrents to rutorrent, which you can do with Prowlarr. You can then extend all of this further with automations. Radarr, Sonarr, and Lidarr are the most popular examples, which monitor RSS feeds of torrent trackers and automatically download the content you want based on keywords. They handle movies, TV shows, and music respectively. By combining these you can get a pretty comprehensive media center experience. I'd note, however, that this stack feels quite hacky and is not easy to set up. I'd only recommend it to someone with fair technical experience and a big passion for consuming media (which I don't personally have, so haven't set up much of this).

Open WebUI

Open WebUI and its younger competitor LibreChat are both self-hosted large language model (LLM) chat interfaces. In particular, they become interesting when paired with self-hosted local AI models through applications such as Ollama or llama.cpp. These chat apps also allow you to integrate custom tools, or MCP servers, enabling your local AI to also access your documents on OwnCloud or other self-hosted software you use. This gives you the power of modern AI agents while running privately on your own server, granted you have the extra money lying around to spend on GPUs.

A Futuristic Stack

While all of the examples above fit quite neatly into our philosophical definition of web3, we can actually do a lot better. The examples either are completely local, meaning that there are no accounts and no online collaboration capabilities, or they require some form of username + password login (ideally you use a self-hosted OpenID Connect (OIDC) provider such as Authentik or Authelia for all your self-hosted apps). We have blockchains and wallets now, and we haven't really started using them to their full potential. So what would that actually look like?

Blockchains

Beyond purely financial use cases, blockchains provide a global censorship-resistant ledger where applications can notarize various actions. While it will never replace databases and services like those provided by self-hosted services, it can help improve some of the qualities we care about. The most basic example of this is websites hosted on ENS. These are static websites distributed over IPFS. The fingerprint (cryptographic hash) of the website is stored on the Ethereum Name Service (ENS). Every time the application needs an update this onchain fingerprint is updated, which leaves an immutable audit trail of when and how the application has changed.

ENS names can also be used to mitigate the risk of running backend servers (such as indexers or sync-engines) for an application. We can simply store a list of redundant services in an ENS text record. When the frontend needs to query data from the backend it first fetches the list of URLs from ENS, then picks one of them to make the actual query. This way no specific URLs are hardcoded into the application. Instead an onchain multisig or other mechanism can curate this list. I've been using this architecture with great success in SimplePage, and gone on to formalize it in an ENSIP (DService) with the additional ability for the user to override the onchain list with a custom URL.

Key to note here is that a "dservice" backend needs to be implemented in such a way that anyone could spin up a node (in the same vein as self-hosted applications mentioned earlier). To achieve this, these services can only rely on three types of data:

onchain data - essentially acting as an indexer
offchain data, hashed onchain - e.g. any data on IPFS, where the hash of this data has been notarized onchain
signed offchain data, identities onchain - any data that is accompanied by a signature by an authorized identity, i.e. an Ethereum address. Onchain there's some sort of registry (e.g. token holders) that decide if an identity belongs to the set whose data should be synchronized.
By relying on these architectural constraints, new nodes will always be able to verify the integrity of the data without relying on trust in existing nodes.

Wallets

The evolutionary landscape surrounding wallets has led essentially all wallet projects to build hyper-financialized products. But wallets can be so much more. One of my earlier projects uPort instead tried to be a generalized identity wallet where all of your financial assets were managed together with your identity information. Taking this one step further, you'll realize that wallets, at their core, are ultimately just key managers. They let users manage their cryptographic secrets in a secure and reliable manner. Not only can they control onchain assets, but they can also control any offchain application data. They are also not restricted to simple signatures, but could also manage encryption keys, which is crucial for any end-to-end encryption in applications. For example, they could manage your email PGP keys (which unfortunately isn't a widely adopted standard for most email users), and could even act as password managers for legacy applications.

One of the great failures of the Ethereum ecosystem is that we don't have a widely adopted wallet standard for encryption and decryption of data. Instead, the only non-financial standard is Sign-In with Ethereum (SIWE), which is primarily focused on authenticating against a backend server. Note that by itself this does not meet the signed offchain data constraint outlined for dservices above, unless the user is prompted with a SIWE request for every interaction they make in the application, which obviously isn't a great experience for the user. A workaround is for the application to generate a random session key client-side, which a SIWE request can sign over to delegate permissions for offchain data (we actually used this approach in my previous project Ceramic). The problem that remained is that all of this data is public. We ideally need an encryption standard in all wallets that applications can leverage.

It's also worth mentioning that wallets are slowly evolving to include private local llm agents. While this removes the need for certain classes of applications because users can simply ask the agent to do the thing for them, sharing data privately will always be a need, regardless whether or not it's done by an agent.

Local-first software

There is a growing desire in the traditional web stack to have more data live locally with the users. This movement is often referred to as local-first software. Interestingly it seems like this movement is on a convergence path with web3 and CROPS principles. This can be sensed in the seven ideals:

No spinners - all your work should feel instant, your computer has a lot of power, you shouldn't have to wait for network roundtrips when you make changes
Don't trap work on devices - traditional software tools like office suites work with files on your computing device, you can normally not access it from other devices unless you use a cloud service
The network is optional - it shouldn't matter if you are connected to wifi or not, better yet if you are connected over bluetooth with your friend you should still be able to collaborate
Seamless collaboration - you should be able to collaborate with your friends or colleagues in the way we are used to with tools like google docs.
The long now - data ownership means that you should be able to access the data a long time into the future, even if the producer of the software you use disappears. This is very similar to the walkaway test often referred to in the web3 community.
Security and privacy by default - this exactly mirrors the P and S in CROPS
You retain ultimate ownership and control - no one should be able to lock you out of your data. Essentially the same as CR in CROPS
Local-first software relies heavily on a technology called CRDTs (Conflict-free Replicated Data Types) as a way of achieving most of these goals. However, since most implementations have focused on the CRDT aspect, authorization is often left out. As it turns out, rich peer-to-peer authorization without some trusted authority or coordination point is not possible in a trustless setting (e.g. any time you interact with someone you don't trust to modify shared data without your consent, which is most online interactions). We actually need authorization patterns that look very much like web3 wallets. This is being realized in the KeyHive research project, which aims to bring cryptographic object-capability auth to CRDTs.

Synthesis

With some amount of creativity we can see how these components come together into a quite compelling web3 stack. Through wallets users control their data in a local-first manner. This data is synced to either fully self-hosted or managed servers. All coordinated through onchain state, be it token balances, dservice text records, or other mechanisms.

The remaining question in my mind is if this pattern will be something that each app implements. Maybe with slight variations based on their own requirements. Or if there is something that looks more like a singular fully encrypted drive (think dropbox or icloud) that is controlled by your wallet. Your computer simply treats it as any other folder on your computer where you store all your files, and you point your private local-llm agent at it.

Conclusion

The next generation of web3 should look less like a pile of financial primitives with centralized frontends bolted on, and more like software that people can actually live in: local-first, private, portable, self-hostable, and coordinated through open cryptographic infrastructure.

A simple test is whether users can leave with their data, copy it, verify what the software is doing, run their own infrastructure or choose among competing operators, share privately without asking permission from a gatekeeper, and keep using the software even if the original builders disappear. In other words, it should pass the walkaway test. If those properties are missing, the product may use blockchains, but it is not really delivering the freedom that web3 promised.

See all posts