Dynamic Applications on DWeb

Recent surge of Ethereum gas fees made it crystal clear not everything belongs to a blockchain. Even before that Aragon decision to move to own blockchain, demonstrated some things better live on their own medium. Here I explore how DWeb could work alongside blockchain, complementing it.

Traditional Web: Not your data

DeFi narrative brought an idea of self-sovereign financial system. As long as you have a private keys, the assets are all yours. No government or company could confiscate the assets unilaterally. This is not the case for data yet.

Your data, which include files, documents, workflows and even identity, are all stored on some server that is operated by some sort of a company. The data are available while the server runs. The freedom we got with personal computers revolution — freedom to operate on whatever data in whatever way you wish — is lost. If the company gets out of business, or a government decides to block or shut it down, your data and associated workflows are at risk.

DWeb: Immutable only

The best attempt to address these risks so far is a concept of content-addressable storage, which is embodied by IPFS and Filecoin protocols. You put a content there, and receive a small string of unique content identifier. If you have access to the identifier, you have access to all the data stored under it, and no one can restrict it. Just like DeFi asset.

Unlike the asset, you could not easily change the data. The asset is based on blockchain smart contract. It contains a workflow for collaboration and changes to the assets. Pure immutable data on IPFS lack this.

Or mutable but restrictive

There are few attempts to add mutability on top of IPFS: OrbitDB, Textile, and some others. They provide you with a capability to create a changeable database on top of immutable IPFS storage. This comes with a restriction that you could only access a database with a specialised software installed on your computer. Say, you set up a database on OrbitDB with custom identity provider (signs updates to the database), custom store (represents all the updates in a form that makes sense to humans or computers), and custom access controller (restricts updates, or state transitions, to the database). To read a database you are required to have it all on your computer. You can not ask a random node in the network for a state of the database, as it does not know how to represent log of updates as it does not have the custom store installed. Nor the node does know if it could apply an update to the database, as it does not have the custom identity provider or access controller installed. This is just too much a requirement for interoperable DWeb.

Dynamic applications on DWeb

What if we put that custom code to IPFS too? We specify in code (JS or WebAssembly) what is considered a valid update, and what constitutes a “canonical” (that makes sense to humans and/or computers) version of a database, and store it on IPFS. We call it ruleset. Then we link the database with the ruleset. Now, any node or client interested in accessing the database, could do that without installing any additional software. It just executes the code linked to the data.

State Transitions

I consider this approach to be a CGI for DWeb. All the modern web stack operates in a paradigm set by Common Gateway Interface in mid-90s. You have some data in a database, you have a thing that accepts input, transforms the data, and provides it to a consumer. This is similar but all of the data and the code live on DWeb, which makes the whole system resilient and interoperable. It opens up a collaboration not limited by client implementation. It lives everywhere. This is fully decentralized web with rich applications, unhindered by blockchain fees.

Alternatively, you could look at it from blockchain perspective. There were quite a lot of BitCoin forks adding one or two features on top. Now all of this features and more turned into interoperable lego blocks on Ethereum. Programmability is king.

So, what?

CGI basically created dynamic Web as we know it. I hope this paves the ground for dynamic DWeb, as an approach for building distributed collaborative systems in addition to blockchains and distributed databases, for building dynamic content.

You can read such dynamic content from any node. It just executes the code stored on IPFS anyway. Consider case of Verifiable Credentials. There is a well defined canonical form of VC document, but rules of how it is issued and revoked could vary. Say, two out of three signatures are required for issuing or revoking a VC document. With our approach the reader is not exposed to the rules, and just gets vanilla VC document no matter how it is issued.

You can create custom workflows to operate on data. Linking data to code creates an opportunity for making dynamic collaborative applications. Recently, Uniswap proposed TokenLists initiative to gather lists of safe to use tokens on Ethereum. We could create a top-level document containing list of all the TokenLists. It is only editable by a limited number of people (and we enforce it in code). The top-level document then references particular TokenLists. These in turn are editable in whatever way their creators imagine, all enforced by code in a ruleset. Somewhat like blockchain, but independent of global state.

A ruleset is data too, so a custom workflow could be applied to it. If ruleset for data represents an application, then ruleset of a ruleset, is a governance procedure to update the application.

We could access external resources from the ruleset, and either check updates based on it, or add new data. We demonstrate it now when requesting external blockchain data for timestamping purposes from a ruleset. This could significantly ease burden of an application developer. She is focused on a small data changes only. It is of ruleset’s responsibility to access external resources, like querying DAO participants, or posting quorum of signatures to a DAO as a single transaction, or even creating a case on Aragon Court.

Far reaching possibility is to add zero-knowledge proofs to a ruleset. This way private data remain truly private, and not exposed to IPFS even in encrypted way.

Is it ready? When can I use it?

I just build a proof-of-concept of the system. Instructions on how to run and explore it are in the README. I have to add few tweaks here and there, so it will be useable soon.