Introduction
This is Part one of a three part document describing a level two protocol for Decentraland. This part will discuss the motivations and the content distribution layer.
Motivation
The motivation behind Decentraverse is to provide a way to provide large content that may not be able to fit within Decentraland itself, like games. An example of this woud be a MMO, where buying enough land may cost millions. Another use for this unbounded and costless land would be personal structures where the owner would like to set their own rules/physical constraints.
Another motivation not touched on in this part of the document is multiplayer, which is currently easier to implement without having to deal with the land continuity issues within Decentraland.
The distribution layer
This section will explain how structure data is loaded, traversed and distributed.
The main mechanism for land distribution is IPFS (InterPlanetary File System), so after the structure has been serialized by the editor it is saved as a unbounded land file with a name which is used in links. An IPFS Daemon will add the file to the Daemon's land directory, overwriting any land file with the same name. The directory is then published to IPFS. Once the directory has been published, the node's IPNS (InterPlanetary Name Server) is updated so all links to that scene are also updated to the newest version. This will prevent links referencing earlier versions. Without this update process, links could end up in dead ends where outdated links do not allow the user to reach the more recent versions of content.
To allow for human-friendly names, we need to create a smart contract which maps from an Ethereum address to the scene creator's IPFS address. This allows for an ENS (Ethereum Name Service) address to resolve to an IPFS entry via their Ethereum address. IPNS is used so that the Ethereum contract will not need to be updated for every minor update to the scene. This avoids unecessary transaction fees. Changes to the Ethereum contract are thus only needed when initially registering a new IPNS address.
On the client side, land is loaded via a link where an IPFS entry is referenced either by a ENS address or by its own hash.
Due to the fact that a directory is uploaded not a single file, the IPFS entry acts like a website, where if no specific file is referenced, the browser will default to the site's index. This allows for one IPNS entry to contain many scenes; this could be used for running many scenes or fragmenting scenes to improve loading time.
Traversing between locations is achieved by using portals. These can be divided into two categories; portals between different land tiles or Planets and connections between scenes on IPFS.
Scene links follow the below simple format:
(dvp://<ens address || ipfs address>/.lnd ) (if a scene name is not used it defaults to index.lnd)
The other form of portal which connects tiles (which may be on different Planets) follows a different, but similar, format:
(dlp:///<x, y>.lnd) (if no land is specifided it defaults to 0,0)
The Planet name is resolved to a Ethereum contract address via a root contract which maps a string to a address.
Both types of portal appear as a simple plane within the scene.
Conclusion
The motivation for the Decentraverse concept is to allow for the creation of large content and significantly altered rules and constraints, without being prohibitively expensive, or causing clashes between differing neighbouring physical rulesets. The distribution layer to implement this can be created by using IPFS, IPNS and Ethereum.
Appendix
A Planet: A collection of land tiles, an example of this is Vanilla Decentraland, which is refered to as Datum within this document.
Introduction This is Part one of a three part document describing a level two protocol for Decentraland. This part will discuss the motivations and the content distribution layer.
Motivation The motivation behind Decentraverse is to provide a way to provide large content that may not be able to fit within Decentraland itself, like games. An example of this woud be a MMO, where buying enough land may cost millions. Another use for this unbounded and costless land would be personal structures where the owner would like to set their own rules/physical constraints.
Another motivation not touched on in this part of the document is multiplayer, which is currently easier to implement without having to deal with the land continuity issues within Decentraland.
The distribution layer This section will explain how structure data is loaded, traversed and distributed.
The main mechanism for land distribution is IPFS (InterPlanetary File System), so after the structure has been serialized by the editor it is saved as a unbounded land file with a name which is used in links. An IPFS Daemon will add the file to the Daemon's land directory, overwriting any land file with the same name. The directory is then published to IPFS. Once the directory has been published, the node's IPNS (InterPlanetary Name Server) is updated so all links to that scene are also updated to the newest version. This will prevent links referencing earlier versions. Without this update process, links could end up in dead ends where outdated links do not allow the user to reach the more recent versions of content.
To allow for human-friendly names, we need to create a smart contract which maps from an Ethereum address to the scene creator's IPFS address. This allows for an ENS (Ethereum Name Service) address to resolve to an IPFS entry via their Ethereum address. IPNS is used so that the Ethereum contract will not need to be updated for every minor update to the scene. This avoids unecessary transaction fees. Changes to the Ethereum contract are thus only needed when initially registering a new IPNS address.
On the client side, land is loaded via a link where an IPFS entry is referenced either by a ENS address or by its own hash.
Due to the fact that a directory is uploaded not a single file, the IPFS entry acts like a website, where if no specific file is referenced, the browser will default to the site's index. This allows for one IPNS entry to contain many scenes; this could be used for running many scenes or fragmenting scenes to improve loading time.
Traversing between locations is achieved by using portals. These can be divided into two categories; portals between different land tiles or Planets and connections between scenes on IPFS.
Scene links follow the below simple format: (dvp://<ens address || ipfs address>/.lnd ) (if a scene name is not used it defaults to index.lnd)
The other form of portal which connects tiles (which may be on different Planets) follows a different, but similar, format: (dlp:///<x, y>.lnd) (if no land is specifided it defaults to 0,0)
The Planet name is resolved to a Ethereum contract address via a root contract which maps a string to a address.
Both types of portal appear as a simple plane within the scene.
Conclusion The motivation for the Decentraverse concept is to allow for the creation of large content and significantly altered rules and constraints, without being prohibitively expensive, or causing clashes between differing neighbouring physical rulesets. The distribution layer to implement this can be created by using IPFS, IPNS and Ethereum.
Appendix A Planet: A collection of land tiles, an example of this is Vanilla Decentraland, which is refered to as Datum within this document.