Abstract
Several districts, including the Red Light District, Vegas District and the University want to build a structure on a single parcel of land where individual rooms or floors in that structure can be owned by different people.
In Decentraland’s current state a LAND parcel is tied to a single Ethereum address, multi-sig wallet or contract which owns the entire of it, anyone with access to that LAND parcel can edit the entire of it.
This proposal defines an portal system which allows the LAND parcel owner to define multiple portals in their LAND which a third party can declare content for.
IPFS
Decentraland uses IPFS to store assets, Assets are defined then uploaded to the IPFS platform where a static IPNS address is returned. This IPNS address is then linked to the LAND parcel, so whenever anyone wants to view the LAND, they make a request to the Decentraland contract to view that specific LAND parcel. The contract returns the IPNS address of the scene, then the client retrieves the scene data from the IPNS end point.
The owner of that IPNS endpoint can then continuously edit the scene and upload the changes to the same IPNS endpoint, with out having to keep reconfiguring the LAND parcel, as the IPNS address is static. Like how a static domain name can point to a changing IP address.
Thinking With Portals
The implementation I am proposing works in a similar way. A LAND owner can create a scene containing A-Minus objects. These objects will then define the dimension of a user changeable area, be it a room or a floor or other.
The LAND owner could define a 5x5x2 area using a box. The tenant could then create a 5x5x2 scene and upload that to IPFS, returning an IPNS address that the tenant controls.
The LAND owner can then configure each object with an attribute that contains the tenant’s IPNS address. The client can then pull the referenced scene from IPNS and replace the a-box with it.
The object would also contain a reference to the ethereum address of the tenant of the portal. This way we can create a chain of trust that can be used later in the portal’s lifecycle.
An example definition might look like
Benefits
This approach creates a landlord tenant model which relies on the rendering engine to resolve, rather than a smart contract. This reduces the complexity of the proposal, as the scene renderer can just recursively render the LAND scenes but it also removes the idea of a smart contract governing rental.
Needs
Allows people to edit an area
Some areas might be private to one or more people
Parcel(s) that are a stack of permissioned boxes
Common stock view when you go to a window or balcony and can see the world.
Suggest that the view from a window uses some sort of view rendering to produce static images which can then be layered in a parallax type setup to give the illusion of depth perception.
We would like to be able to have a feature where we can generate a static view at a point in space and time. So like being able to put a camera at x1,y1,z1 pointing at x2,y2,z2 with options on time/delay to take the snapshot. The request would then join a ‘render queue’ which would be serviced by multiple render processes. The process would then need to update an instance of the snapshot - perhaps with the onus on the parcel developer to provide some callback
Some Musings from carl.fravel
I want to be able to lease a floor of an office space or apartment building, and optionally to allow the tenant to have delegated building rights within it.
Another possible approach, which is what is done in Second Life:
the ability to subdivide the parcel (called Sim or Region there) into smaller pieces at the ground level (called Parcels in SL, but we don’t have a name for it here, maybe sub-parcel?)
The ability to delegate build rights to a member of a group associated with that SL Parcel (but not necessarily give all members of that group stronger rights) (SL groups have roles, and roles have a checklist of rights)
The ability, through scripted "security devices" to limit where an avatar can go (both in terms of the SL parcel, but also in terms of a piece of 3D space, like a floor in a building, or a particular skybox). They could theoretically have delegated building rights anywhere in the vertical space of the parcel, but can actually only do so where the security arrangements allow them to be.
We would have to modify that because unlike in SL, where building is done inworld in the same client and mode as the viewer, in DCL we have a separate upload and view process, so the controls on building in a specific xyz zone would have to be imposed at upload time.
Abstract Several districts, including the Red Light District, Vegas District and the University want to build a structure on a single parcel of land where individual rooms or floors in that structure can be owned by different people.
In Decentraland’s current state a LAND parcel is tied to a single Ethereum address, multi-sig wallet or contract which owns the entire of it, anyone with access to that LAND parcel can edit the entire of it.
This proposal defines an portal system which allows the LAND parcel owner to define multiple portals in their LAND which a third party can declare content for.
IPFS Decentraland uses IPFS to store assets, Assets are defined then uploaded to the IPFS platform where a static IPNS address is returned. This IPNS address is then linked to the LAND parcel, so whenever anyone wants to view the LAND, they make a request to the Decentraland contract to view that specific LAND parcel. The contract returns the IPNS address of the scene, then the client retrieves the scene data from the IPNS end point.
The owner of that IPNS endpoint can then continuously edit the scene and upload the changes to the same IPNS endpoint, with out having to keep reconfiguring the LAND parcel, as the IPNS address is static. Like how a static domain name can point to a changing IP address.
Thinking With Portals The implementation I am proposing works in a similar way. A LAND owner can create a scene containing A-Minus objects. These objects will then define the dimension of a user changeable area, be it a room or a floor or other.
The LAND owner could define a 5x5x2 area using a box. The tenant could then create a 5x5x2 scene and upload that to IPFS, returning an IPNS address that the tenant controls.
The LAND owner can then configure each object with an attribute that contains the tenant’s IPNS address. The client can then pull the referenced scene from IPNS and replace the a-box with it.
The object would also contain a reference to the ethereum address of the tenant of the portal. This way we can create a chain of trust that can be used later in the portal’s lifecycle.
An example definition might look like
Benefits This approach creates a landlord tenant model which relies on the rendering engine to resolve, rather than a smart contract. This reduces the complexity of the proposal, as the scene renderer can just recursively render the LAND scenes but it also removes the idea of a smart contract governing rental.
Needs
Some Musings from carl.fravel I want to be able to lease a floor of an office space or apartment building, and optionally to allow the tenant to have delegated building rights within it.
Another possible approach, which is what is done in Second Life:
We would have to modify that because unlike in SL, where building is done inworld in the same client and mode as the viewer, in DCL we have a separate upload and view process, so the controls on building in a specific xyz zone would have to be imposed at upload time.