Building a Super dApp together on the Internet Computer

Pills in the pill

I want to bring back Open Internet Services.

Why?

I’m not interested in tiny improvements. What I love is creating something disruptive, something that has never been tried before.

Today, I’d like to present a new approach to developing applications, made possible exclusively by the Internet Computer.

This experimentation brings back the original vision of Open Internet Services and has the potential to propel the Internet Computer ecosystem years ahead of any competitor.

This approach addresses key issues currently faced by the ecosystem but also, if executed properly, could lead the way toward a new economic paradigm that transforms Web3 forever.

Before talking about it, I’d like to go over how we build on the Internet Computer, as well as the common problems faced by builders. Only then, will we be able to bring the pieces of the puzzle together and unlock it.

How to build a dApp on the Internet Computer?

Building an application on the Internet Computer involves developing a canister, which acts like a decentralized server. A canister consists of a WebAssembly module and memory. Canisters can be written in various languages, such as Motoko, Rust, or TypeScript.

Here are a few important things to note about canisters:

1. Canisters on the Internet Computer use the actor model. This means that each canister has its internal private state, which can only be accessed by other actors through asynchronous messages.

This design enables the Internet Computer to scale, as it allows an increasing number of canisters to run in parallel — but also has issues for composability as we’ll see later.

2. Canisters store internal energy called cycles, which they use to pay for their own computation and storage costs. This allows developers to pay for user’s fee and for canisters to pay to hold and share economic value.

3. Canisters can be controlled and owned by users, making it possible for users to truly own their data and create user-centric protocols.

To sum it up, canisters are not only entirely new building blocks for applications but also a new primitive for businesses, as they can be owned and acts as economic agents.

These three points are important, so keep them in mind for later.

Problem 1: Sharing value & users

One of the biggest complaints users have when using dApps on the Internet Computer is that they cannot see their funds across multiple dApps.

For example:

• When I log in to OpenChat, I have one wallet, where I own 10 ICPs.
• When I log in to Nuance, I have a different wallet, where I don’t own any ICP.

Based on our first point, this user experience is simple to explain. Since each canister has its own private state, it is difficult for developers to share user data or value across multiple applications.

On the contrary on Ethereum, the entire state of the blockchain is synchronously accessible to any dApp. This means that, at any point in time, dApps can access and interact with the current state of the blockchain. This makes it much easier for builders to share data value across the entire Ethereum ecosystem.

Problem 2: Inter-canister calls

Here is an extract from the official documentation: “One of the most important features of ICP for developers is the ability to call functions in one canister from another canister. This capability to make calls between canisters, also sometimes referred to as inter-canister calls, enables you to reuse and share functionality in multiple apps.”

Since the launch, it was assumed that developers building on the Internet Computer would use inter-canister calls to communicate with other services. The ultimate vision of the Internet Computer was for multiple services to interact smoothly with each other.

But let’s face it. In reality, those inter-canister calls suck.

• They add extra latency to dApps. At a minimum, they add a consensus round (around 2 seconds), but this can increase to 6 or 8 seconds if the called canister is on another subnet. Multiple inter-canister calls result in compounded latency, which quickly adds up and result in an awful user experience.
• They require a high level of trust. When calling another canister, you exit your trusted execution environment to interact with another service, which might be malicious. For example, if the service is controlled by another user or a malicious DAO, can you trust it?

One of the biggest problems with the Internet Computer illustrates this second points. Using inter-canister calls to communicate with other services can make your own canister impossible to upgrade — read more about this topic from 2022 for details. This problem hasn’t been solved to this day.

Problem 3: Composability

One of the core value propositions of Web3 is composability. However, as we’ve just discussed, the Internet Computer’s composability is not as impressive as it initially appears.

The original vision of Open Internet Services is one where:

• Developers build on top of each other’s work.
• Developers share users and economic value.
• Developers can focus on building services, allowing entrepreneurs to create use cases that attract users on top of their services.

However, why would anyone call an untrusted external service that adds latency when they could simply copy the code and run it within their own canister?

Problem 4: Gated ecosystems

Most current applications on the Internet Computer are not user-owned; they are DAO-owned. Instead of surrounding control to big tech, we have surrounded control to SNS-DAOs. Within the Web3 vision, DAOs are necessary but current DAOs on the Internet Computer are set as restrictive gates, this makes it more difficult to:

• Establish standards and define protocols.
• Encourage collaborative development.
• Share liquidity and user bases.

The current Internet Computer ecosystem is divided into many DAOs, each leading its own micro-ecosystem.

Are we all working towards a dead-end? What comes next?

Solution: Put the actors in the actor

I believe the solution to most of our problems can be found in nature.

It might seem unrelated at first, but in nature, there exists a structure known for maximizing energy efficiency, optimal resource distribution, and adaptability. This structure is called a fractal.

If we are truly building the Internet Computer — the platform on which all of humanity’s services will be rebuilt — then we are creating the foundation to maximize human productivity, resource sharing, and adaptability. So let’s take inspiration from fractals.

Keep that in mind and let’s come back to those inter-canisters calls.

I may have been too harsh earlier — they’re not that bad. The actor model greatly simplifies interactions between canisters and creates an incredibly composable pattern. Now, what if I want to leverage the actor model without suffering the downsides of inter-canister calls?

Here is the idea: I want to put internal actors into our canisters. The concept of internal actors leverages composability while avoiding the following problems:

• Latency: The latency for internal actor calls would be reduced to milliseconds since all actors reside in the same canister, eliminating the need for a new consensus round.
• Trust: Trust is inherently ensured because all actors live in the same canister, which serves as our primitive unit for creating a trusted environment.
• Ownership: In this paradigm, all actors reside in a user-owned canister, allowing DAOs and dApps to collaborate without competing for control.

To make this paradigm successful, it’s imperative to make the experience of building internal actor as close as possible to the current experience of building canisters.

Collaborative building

Now imagine a group of people deciding to follow this pattern, dividing the work into different units:

1. Wallet: One group of developers creates a wallet actor.
2. Identity: Another group develops an identity actor.
3. Social: A third group builds a social actor.

These developers only need to focus on building their own service and how it interfaces with the rest of the world. All of these modules will be integrated into a user-owned canister.

The advantages of this approach are so significant that they deserve an entire article, but let’s highlight some key benefits.

Reducing the cost of user-acquisition

In this model, user acquisition doesn’t have to come from each individual builder but can be strategized collectively. Once a user is acquired, they create their own canister and load it with various modules.

Only one effective user acquisition channel through a highly appealing dApp will make all our builders incredibly successful.

Unlocking Composability

As a developer, I don’t want to reinvent and compete with protocols that have already shown traction. Instead, I’ll simply plug into those protocols.

With this model, composability becomes a necessity to survive and thrive. Building Open Internet Services now is technically and economically feasible.

Imagine how powerful an event protocol could be if it could rely on the social protocol to access a user’s contacts, friends, and coworkers. Similarly, imagine how powerful an identity protocol could become if it could leverage a wallet protocol to stake into your friend’s reputation.

Adopting a protocol mindset

Today, too many builders focus on creating platforms or applications instead of protocols. Although this issue is widely recognized, explaining the difference between “building a dApp” and “building a protocol” often causes confusion.

By adopting this new approach, it’s easier to understand what a protocol, a dApp, and a platform should look like, and what building each entails.

• A protocol combines actors across multiple user canisters and their communication methods. We need protocols for identity, event planning, wallet management, treasury management, governance, and more.
• A dApp is the infinite combination of use cases for these internal actors. We need dApps to manage our calendars, communications, games, wallets, and more.
• A platform is how users interact with dApps and protocols. This interaction can be through traditional web applications, AI chatbots, and, in the coming years, the metaverse.

Are you bold enough to try it?

The idea works on paper. Now it’s all about:

• Creating the technical framework that makes this building approach possible. I believe that the Motoko language already contains some of the primitives to make this happen.
• Distributing economic value fairly among each of us and developing the first channel of user acquisition as a group.
• Putting our ideas on the table and distributing the workload among builders.

In my next articles, I’ll explain what are the necessary steps to make this vision real and how it could lead our civilisation into a new economic paradigm. This vision is incredibly exciting and I believe it is what the Internet Computer was always meant to be used for.

Our goal is to revive Open Internet Services, which is why we created the Open Internet Summer. If you also believe in making this vision real, join us. But don’t forget rule #1: “What happens at Open Internet Summer stays at Open Internet Summer”.