My Vision for a Decentralized Virtual Landspace

Instead of focusing on bandwagon nonsense like building a “social” “economic” “platform” for making money, decentraland should focus on making a protocol that anyone can easily use to explore the shared, decentralized registry of “land” while still providing a desirable experience for users. The purpose of the protocol is explicitly to facilitate the exploration of this shared land registry and the content within.

Keep the Land Registry

Honestly the best idea in the whitepaper is the land registry, which is also the simplest to understand and most universally useable. It’s simply a hashtable of what content should be displayed at a specific space in our virtual world.

Scrap the Native Script

Instead of requiring that the content of a space be defined in the first-party scripting language, support web standards and allow content creators to provide any type of web content as “content”. This turns the decentraland client into a “browser” as we understand it today, where it facilitates discovery and usage of third-party content, providing an overall more valuable experience.

To make this a concrete example, my 3D poker app (which is a traditional JavaScript dapp client that interfaces with an Ethereum node), could be hosted at the content_hash related to my space. If a user wants to interact with my content, the decentraland client simply delegates operation to the dapp client, much like opening the app in a new tab or an iframe. In this case, it would use WebVR to render a poker table. You’ll notice that this is basically the exact same concept as a Dapp Browser like Mist or MetaMask. By using web technologies, the browser doesn’t place any additional restrictions on the content it can display.

The Overworld

I’m going to start referring to the virtual world that displays the land within the registry as the “overworld”. This provides a nice distinction between the world that the decentraland client renders and the worlds that third-party content can also optionally create.

Keep the Seamless Overworld

You’ll correctly notice that this removes the ability of the decentraland client to render a seamless overworld; we don’t know what the visual result of rendering a dapp client will be (especially not from the “outside-looking-in”) if we have to defer that rendering to the dapp.

To remedy this and provide the experience of a seamless, never-ending virtual world, the “content” referenced by a space can define, using something similar to the proposed scripting language, some sort of experience that is displayed in the overworld before the third-party dapp is interacted with. This could be a “storefront” 3D model, where the third-party dapp is displayed once the user enters the virtual door, or it could be a 3D poker table with an open seat that launches the poker dapp once the user “sits down” at the table by interacting with it. The important part is that it provides a seamless world while also delegating the actual logic to tried-and-true web technology.

You’ll notice that we haven’t gotten rid of the core experience of walking around a virtual neighborhood in the overworld; that still exists. Additionally, the decentraland client can provide information about the overworld to the space’s rendering logic (like reflection maps), and the rendering script can fetch third-party information like the number of connected users to influence how a space is rendered (by populating a poker table with avatars).

This sort of architecture combines the best of both worlds; a seamless overworld and unlimited creative license to third-parties in how they create their decentraland content.

While we’re at it, we can just call the scripting language JavaScript and request that the content render to WebGL… oh yeah, web standards. Imagine that every piece of land content provided a WebGL scene as part of its content bundle; that scene can be directly integrated into the decentraland client’s WebGL overworld and it all just works because of standards.

obviously there are implementation details to be considered, but this isn’t a whitepaper

Payments

We don’t need to reinvent micropayments. Let the hundreds of other smart people working on that problem handle it for us. Decentraland could leverage the 0x or Swap protocol to handle p2p transactions of ERC23 assets. Make it extremely easy to use, but don’t integrate it into the protocol.

If one of the third-party spaces implements an RPG item as an ERC23 token, it can be traded in any arbitrary manner using one of those protocols for another ERC23-based asset (like ETH or whatever). The economy exists without the need for MANA. In the case of 0x, it would be beneficial for the decentraland foundation to run their own relayer to facilitate matching orders across the ecosystem. This shouldn’t be integrated into the protocol, though, but should exist as a convenient standard to be optionally included in a client.

If a third-party app wants to charge for their services, they can do so in literally any fashion already possible. Again, we don’t need to reinvent the wheel here. The decentraland client should facilitate this transaction ala MetaMask, but, again, should not limit the possibilities by defining them explicitly in the spec.

Implementing the Overworld

One of the neat ideas that I’m excited about with this vision is that the rendering of the overworld (i.e., what does this map[(x, y)]content actually look like), can be deferred to the decentraland client. If the client wants to represent it as an infinite flat plane that you can walk around in, that’s totally reasonable. If it wants to represent the overland as an art gallery where each space is a piece of art on the wall like Mario64, that’s also cool. The important part is that the client satisfies the protocol by facilitating access to the content associated with each land parcel.

A Decentraland client could render third-party content as art on a gallery wall, as long as it fulfills the protocol by facilitating access to the shared state of “land”.

This brings me to another important point; the p2p communication required to render the overworld (i.e., player locations, voice chat, and other interactions) needs to be communicated over some medium. In the whitepaper, the authors suggest that landowners will support these bootstrap nodes. What makes more sense, though, is to have the author of the decentraland client support the bootstrap node; users of a specific decentraland client (say, the infinite-plane client) know for certain that they’ll be able to communicate with users that are running the same client. The cost of hosting a bootstrap node is negligible, and could perhaps be subsidized by donations or a fee for using the client, assuming the client provides value that users are willing to pay for.

By virtue of tying bootstrap nodes and clients together, a decentraland client can assume that everyone a user is connected to is also using a version of that client, and can display a uniform, seamless world.

In a client that allows users to float through 3D space to explore the world instead of being tethered to the ground plane, the client can 1) broadcast a user’s z coordinate and 2) assume that everyone else will be broadcasting one as well.

The separation of client and bootstrap server also has another side effect; by using a different bootstrap server, we can effectively create different “worlds” ala Runescape and WOW; users only interface with other users they’re connected to, but access a shared world state (the land hashmap). This allows for private worlds (host a bootstrap server yourself and tell your friends the password, and now only you and your friends can use it to initiate a p2p connection).

Integration with Space Content

To facilitate an integrated experience, the decentraland client can provide developer-friendly APIs and information to the third-party client like the identity of the user that has entered the space, a texture map of the world “outside” of the space (if you want to render that as a “sky”, for example, so you can “see outside” while inside the third-party experience). The decentraland client can also provide a payments api that third-party content can use. It could present a native prompt for sending an Ethereum transaction (ala MetaMask), allowing third-parties to trade in-game items, purchase content, or otherwise interface with their smart contracts.

To Summarize

The proposed protocol exerts too much control over content, which is ironic as hell, and includes a meaningless protocol token and artificial economy, which might be a concealed attempt to funnel money to the early investors. But the core concept of decentraland is based on some decent ideas.

My vision lays out a much more reasonable protocol for governing the exploration of land based on web technologies, lowering barrier to entry without stripping creative control from third-party experiences and content.