Web3: the Unruggable API

by @threepwave and @NiftyPins Aug 5th, 2022

Recently, Minecraft banned all NFTs from their game. NFTWorlds is one of the prominent on-chain products built on top of Minecraft. People who own NFTWorlds NFT’s can explore their worlds in Minecraft and the team was in active development with Minecraft as their primary platform. Like that, they are shut down and have to discontinue any and all integration with Minecraft.

Minecraft's message banning all NFT's

The price of their NFT cratered.

We believe that blockchain technology is the best way for developers to protect themselves against platform providers revoking access. This narrative will repeat itself time and time again as web2 companies struggle to retain control.

In this piece, we speak to some of the challenges of developing in a web2 world, explore how the public blockchain flips this narrative in web3, and explain why licensing is key to creating a world that developers can create without permission or fear. Whether you are a developer or just curious about web3, this article speaks more to web3 concepts rather than to code.

Web2 was largely known for the development and mainstream adoption of social networks—it was also the era of the application programming interface (API). Instead of releasing software as a black box with only one specific set of features, companies deployed APIs that enabled developers to build on their services. This led to an explosion of interconnected web apps. But there was a catch: developers were at the mercy of the company that owned the platform and could have the rug pulled out from under them at any time. This feature of web2 has burned most developers at one point or another. We’ve been burned many times. However, there is a sea change happening in web3 that will embolden devs to build the next great wave of software.

Building on a Company’s API: The Devil’s Bargain of Web2

Any developer who cut their teeth in web2 knows that consuming a company’s API comes with a devil’s bargain:

  1. Promising to play nice - If at any point in time you pass the API limits or use the data in a manner that violates the terms of service (ToS), the company can shut off your data firehose.
  2. Willingness to embrace change - At any time, a company can modify the rules of engagement, both in terms of the ToS and the endpoints exposed and developers must quickly adapt to that change.

To use the old developer saying: this is not a bug, it’s a feature. These web2 companies are not just cutting off access, but rather extracting value from developers until these programmers are no longer needed. Many services and social networks were built on the backs of developers, and when it became convenient for the company, they shut off the firehose. Chris Dixon highlights this phenomenon in his piece Why Web3 Matters, where he shows that as platforms move up the adoption S-curve, the relationship between developers goes from cooperative to competitive.

Chart describing the relationship between platform owners and participants (source: cdixon.org)

Apps we’ve built on web2 APIs have been affected on several occasions, resulting in:

  • A business completely shutting down after Twitter no longer allowed clients to pull in tweets
  • A personal project for creating reading lists for friends and families breaking after Goodreads changed access restrictions
  • The ability to create World of Warcraft add-ons and modifications suffering a slow death as the organization effectively locked down developer access

Our experience is not atypical: anyone who has built an app in web2 that’s dependent on a company’s API has had the experience of having the rug pulled out from under them.

Jumping through Hoops for Access

Even before ever connecting to a web2 API, a developer must jump through hoops just to have access. This access is often connected to receiving an API key that can be used within your application to connect to a given service.

These keys aren’t just handed out to everyone—you must fill out forms, prove your identity, and gain approval just to get one. And unless you are spending a lot of money, your access will be watered down and can be shut off at any time if you exceed the limits of the free tier.

A curious developer must ask permission from the gatekeepers. This walled-off turf, restricted by those who wish to retain their power, runs counter to the ethos of the open, connected ecosystem that the web was intended to be.

Fortunately, web3 aims to right a number of these wrongs.

Web3: The World’s Largest Open API

Coming from a web2 world, we know that the current web3 landscape causes many developers to bristle. Some are turned off by what they perceive as a get-rich-quick venture for grifters, and others are concerned about the environmental impact of blockchain networks. we understand both concerns and share them, but we believe they are temporary.

As the space matures with more users, the speculative nature of web3 will begin to see fewer wild swings. The grifter association will give way to a new way of storing and exchanging value. And as Ethereum moves from a proof-of-work to a proof-of-stake mode, the environmental impacts will begin to be blunted. Yes, the blockchain consumes energy, but so do server farms that power today’s internet experience. And there are web3 companies and NFT projects that pledge to offset emissions.

Looking past these two obstacles reveals the defining characteristic of web3: it’s the world’s largest open API that can be queried without permission. This is a powerful concept:

1. Blockchain data is public with no API key required to query. The very nature of the blockchain is that all the data is public; it’s not hidden in a backend database, locked away in a company’s vault. Everything is accessible to any curious individual. As data is written to the blockchain, it’s available to use. So be it weather data or basketball statistics, anyone can call on that information. And because no API key is required, developers can begin querying the blockchain right now.

2. Changing endpoints takes considerable effort. Ethereum smart contracts—applications that are written in Solidity and stored on the blockchain—are immutable. This means that the endpoints that a developer calls on don’t change. In fact, if a company wants to make modifications, they must publish an entirely new contract. Doing so requires significantly more effort than it takes for a developer to push a change to their web2 company’s server that will impact your app and the old contract can still be accessed.

3. One query can easily pull data from multiple sources. Imagine what it would take to craft a query to return the five most recent posts from Twitter, Instagram, and Facebook. In web2, this seemingly simple task is actually quite complex, as a developer has to not only secure the API keys for each of these services, but also stitch together lines upon lines of code to make it happen. Each service has its own data format and api’s. This isn’t the case with the blockchain: you could call on four different contracts with a simple four-line function.

Modular Data: The Building Blocks of Web3

Beyond simply querying data, web3 gives developers the opportunity to use it in exciting ways. Similar to Lego bricks, data that is stored on-chain (that is, data written directly to the Ethereum blockchain rather than being stored in an off-chain location like a centralized server) is modular and can be used to build novel things. The term used to describe this in the web3 space is “composability.”

As an example, take a look at the Crypts and Caverns project, a collection of 9,000 algorithmically generated on-chain maps. Each space is defined by five key variables:

  • Size: The width and height of the map.

  • Layout: A square set of 0s and 1s that demarcate the walls from the floor.

  • Entities: Special tiles on the map that represent either doors or points of interest.

  • Environment: The suggested “mood” of the map.

  • Name: The title of the map.

All of this data is stored on-chain with a pixel renderer that can visualize the map in the following way. See, for example, Crypts and Caverns dungeon number 8138:

Crypts and Caverns dungeon number 8138

Because this map’s data is accessible on the blockchain and written in a composable format, developers can query it and transform it into something new. For example, the Heroes used Crypts and Caverns primitives as a foundation for creating their dungeon crawler game. Here is how they transformed the above NFT for use in their game:

Heroes dungeon number 581

The developer, MerlinTheBlue, was able to do this permissionlessly, without having to petition for an API key, to create something new from a piece that already existed. And they could build it confidently, knowing that the data exists immutably and will always be accessible—it would be impossible to pull the rug out from under them. But there is another component of projects that a developer must understand before building on top of an existing project: licensing.

CC0: The Open-Source License of Web3

While a developer can access and build on top of blockchain data, it’s imperative that they understand that licensing still matters. Just as a physical artist can get in trouble for ripping off proprietary logos and characters, so too can a developer in this digital space. However, in web3 many projects have begun to place their work in the public domain with the CC0 license.

Developers should think of the CC0 license as an open-source license for intellectual property. The Nouns project was one of the first major efforts in the NFT space to put _all assets _in the public domain. This means that devs and artists can use the Nouns intellectual property, from the code to the artwork, in their own projects. From this, we have seen an explosion of “nounish” derivatives, including digital NFTs, a Super Bowl commercial, and physical sunglasses, to name a few.

NOTE: While developers are free to use Crypts and Caverns (it is placed under the CC0 license), I’d love to hear more about your plans and help you make them happen. Reach out and drop me a line in the Crypts and Caverns discord!

Developers should look for the CC0 license if they want to ensure that building their work on top of another project will create a project that is truly “unruggable.” Project creators often list the licensing on the website, denoting how the IP can be used in this way opens it up for future changes. To date, this has often resulted in loosening the reigns with respect to the IP (as Yuga did with the CryptoPunks license when they acquired that project). However, this ability to dynamically change the licensing means that a creator can also_ go in the opposite direction _and make it more restrictive. we see this in photography, where a Flickr user can change the license for a particular photo from commercially available to editorial use by merely toggling a switch. Projects like Terraforms by Mathcastles solve this problem by explicitly embedding their license in the immutable contract itself.

Terraforms embeds their license directly into the contract

Coding without Fear

Placing a web3 project in the public domain allows developers to code with impunity. Rather than asking permission to access the data, they can build. Instead of cutting through IP red tape, they can let their imagination run wild.

This is a paradigm shift for developers, so we must learn to ask ourselves: What would you build if you weren’t afraid? If a service couldn’t lock your firehose down? If you didn’t have to request an access token? If you knew that things would not change? How would you build differently? For me personally, asking these questions is freeing, daunting, and—most of all—thrilling.

“Thou Mayest” -timshel

Borrowing a phrase from timshel, a community leader in the decentralized and public domain Loot (for Adventurers) project, instead of having “NO!” at the back of their minds, developers are encouraged to innovate with a “thou mayest” ethos. And in web3 CC0 projects, this permission is both freely given and incredibly difficult to revoke. So rather than building on the shifting sands of web2, why wouldn’t a developer prefer to build on the rock-solid foundation of web3? To build on an unruggable API? This is one of the pillars of web3 that excites me the most.



Born in the 80's


I'm an engineer turned communications professional who loves telling web3 stories.

Born in the 80's


I'm a child of the 80's who never grew up. I make pixel art using javascript and solidity.