[WIP] draft: Loading Scenes

dsp/0021.md

@@ -0,0 +1,67 @@
+<pre>
+  DSP: 0021
+  Title: Loading Parcel Content
+  Author: Esteban Ordano <esteban@decentraland.org>
+  Status: Draft
+  Type: Standards
+  Created: 2019-01-10
+</pre>
+
+# Loading Parcel Content
+
+## Introduction
+
+This document proposes a solution to what should be the process for loading parcel scenes into the Decentraland client. This involves a number of considerations:
+
+* Content location resolution: Determine what is the latest authorized content for a particular parcel
+* Incentives for content storage and bandwidth
+* User experience, optimizations and showing partial progress
+* Failure modes and error recovery
+
+## Content Location Resolution 
+
+Like IPNS, we will implement a Distributed Hash Table (DHT) in order to identify what is the latest signed information for a parcel. This means that there's no on-chain record of what is the current content that should be displayed on each parcel
+
+The resolution of the DHT could be helped by some on-chain indicator of where to find this (an IP address or some other indication of how to create a connection). 
+
+The server we call the "content-server" is intended to provide a gateway into a better way to store content, more centralized, but in a way that can be copied and pasted. This means that one can make a mirror of this centralized gateway.
+
+The centralized gateway is compatible with IPFS. It stores the data on disk or on an S3 server.
+
+2. On multiplexing scene.json files into different versions
+
+If one has a scene.json for parcel A, there's a problem that we can't deploy into parcel B because if my address is what's making the reference then there's a problem with DHT nodes dropping the previous message.
+
+We need to do a multiplexation of the scene.json data
+
+3. Showing progress
+
+We need to set up a number of assets that are mandatory to download before the scene is rendered. This allows the client to show a "progress bar" of what is being downloaded.
+
+This is a field on the scene.json file. By default, it should be assumed that all the files in the root folder must be downloaded. Parcel developers pay a penality for creating a scene that has too many files or weights too much, as users might not get to see their scene load.  Developers should look for a specification of how to improve this performance.
+
+Once there's a resolution about what content to display, we should provide a "download manager" that can hint that we should be prfetching some data. This would be a nice to have for scripts to handle cache invalidation.
+
+We should be cautious about how many megabytes can one download by the client. I don't think it's too many.
+
+## Sequence
+
+The client should:
+
+1. Get the following on-chain information for a parcel:
+    a. Who the owner is
+    b. Who the updateOperator is, if present
+
+2. Ask the DHT or content server what the latest info is for the parcel's owner and updateOperator
+
+3. Use this info to eemultiplex the parcel.json file for a particular parcel
+
+4. Based on the parcel.json file, create a mapping from CID to IPFS addresses
+
+5. Look into the "prefetch" field of the scene.json file
+    a. If no "prefetch" field exists, then download all the assets inside the content folder
+    b. If there is a prefetch field, download only the assets on the prefetch field
+
+6. When all the prefetch assets are downloaded, start running the main script
+
+7. As required by the script, download new assets. It would be great to penalize scenes from the client for doing abrupt requests, like trying to render a model that hasn't been prefetched.